public inbox for [email protected]
help / color / mirror / Atom feedDo 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]>
2025-05-21 06:05 ` Re: Do stuck replication slots prevent autovacuum of running entirely? Laurenz Albe <[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 04:34 Do stuck replication slots prevent autovacuum of running entirely? Marcelo Fernandes <[email protected]>
@ 2025-05-21 06:05 ` Laurenz Albe <[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