Re: Disabling vacuum truncate for autovacuum
Jeremy Schneider <schneider@ardentperf.com>
From: Jeremy Schneider <schneider@ardentperf.com>
To: Will Storey <will@summercat.com>, pgsql-general@lists.postgresql.org
Date: 2024-12-26T20:21:08Z
Lists: pgsql-hackers, pgsql-general
On Mon, 16 Dec 2024 16:25:06 -0800 Will Storey <will@summercat.com> wrote: > I would like to disable vacuum's truncate behaviour for autovacuum. > Previously I had an outage due to its access exclusive lock when it > was replicated to a hot standby. > > When that outage happened it was from a VACUUM call in a cronjob > rather than autovacuum. I now run such VACUUMs with TRUNCATE false > which avoids the issue for these. However I've realized that > autovacuum could cause this as well. This is of interest to me > because I'm looking at tuning autovacuum and getting rid of the > cronjob, but I've realized relying on autovacuum could be dangerous > because of the truncates. Can you tell us a little bit more about the outage? Autovacuum is designed to quickly relinquish this lock if there is any contention, and the dangers of disabling autovacuum are significant, so your statement about autovac being "dangerous" will raise a lot of eyebrows. Did your outage involve hot standbys serving read-only traffic, or did it only involve a read-write database? What was the exact nature of the outage and how did you narrow down the cause to the exclusive lock held specifically during an autovacuum truncation? -Jeremy
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Expand comment for isset_offset.
- 7d559c8580f7 18.0 landed
-
Add vacuum_truncate configuration parameter.
- 0164a0f9ee12 18.0 landed