public inbox for [email protected]  

help / color / mirror / Atom feed

Do stuck replication slots prevent autovacuum of running entirely?
2+ messages / 2 participants
[nested] [flat]

* Do stuck replication slots prevent autovacuum of running entirely?
@ 2025-05-21 04:34  Marcelo Fernandes <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: Marcelo Fernandes @ 2025-05-21 04:34 UTC (permalink / raw)
  To: [email protected]

Hi there,

I am trying to understand if a stuck replication slot would be sufficient to
stop an autovacuum of even starting.

Couldn't the autovacuum process start, but fail to remove dead tuples that
are still necessary by the replication slot? Why would it prevent autovacuum
of even starting instead?

Thanks.






^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Do stuck replication slots prevent autovacuum of running entirely?
@ 2025-05-21 06:05  Laurenz Albe <[email protected]>
  parent: Marcelo Fernandes <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Laurenz Albe @ 2025-05-21 06:05 UTC (permalink / raw)
  To: Marcelo Fernandes <[email protected]>; [email protected]

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.
> 
> Couldn't the autovacuum process start, but fail to remove dead tuples that
> are still necessary by the replication slot? Why would it prevent autovacuum
> 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






^ permalink  raw  reply  [nested|flat] 2+ messages in thread

end of thread, other threads:[~2025-05-21 06:05 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-05-21 04:34 Do stuck replication slots prevent autovacuum of running entirely? Marcelo Fernandes <[email protected]>
2025-05-21 06:05 ` Laurenz Albe <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox