Message-ID: <f6ab24958373f40b44ae68e3a524740ff7df8bd2.camel@cybertec.at>
Subject: Re: Do stuck replication slots prevent autovacuum of running
 entirely?
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Marcelo Fernandes <marcefern7@gmail.com>, 
	pgsql-general@lists.postgresql.org
Date: Wed, 21 May 2025 08:05:19 +0200
In-Reply-To: <CAM2F1VP11Pv7QcVjTzM_X_uNDvd_qPYvGAnneU-Fn8hW2umFPA@mail.gmail.com>
References: 
	<CAM2F1VP11Pv7QcVjTzM_X_uNDvd_qPYvGAnneU-Fn8hW2umFPA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.1 (3.56.1-1.fc42) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/f6ab24958373f40b44ae68e3a524740ff7df8bd2.camel%40cybertec.at>
Precedence: bulk

On Wed, 2025-05-21 at 16:34 +1200, Marcelo Fernandes wrote:
> I am trying to understand if a stuck replication slot would be sufficient=
 to
> stop an autovacuum of even starting.
>=20
> Couldn't the autovacuum process start, but fail to remove dead tuples tha=
t
> are still necessary by the replication slot? Why would it prevent autovac=
uum
> of even starting instead?

I cannot think of a reason why an abandoned replication slot (not sure what
you mean with "stuck") would keep an autovacuum worker from starting.

Typical reasons why autovacuum doesn't start running on a table are:

- there are already "autovacuum_max_workers" worker processes running

- the thresholds for dead or inserted tuples have not been crossed

- the statistics collector has a problem and doesn't gather statistics;
  this applies mostly to v14 and older, see
  https://www.cybertec-postgresql.com/en/stale-statistics-cause-table-bloat=
/

- the parameter "track_activities" was disabled, so that PostgreSQL doesn't
  collect statistics

- the functions "pg_stat_reset" or "pg_stat_reset_single_table_counters"
  are called repeatedly and wipe out table statistics

Yours,
Laurenz Albe