Repository navigation
fix(db): throttle autovacuum on the largest tables so vacuum WAL bursts stop stalling commits - #9087
Merged
Merged
Conversation
…ts stop stalling commits Vacuuming these tables writes WAL, mostly full-page images, faster than the synchronous standbys flush it, so every write commit on the primary waits for a standby until the vacuum ends. A per-table autovacuum cost delay and limit, on each table and its TOAST relation, cap that rate. The ALTERs are catalog-only under SHARE UPDATE EXCLUSIVE: no rewrite, and reads and writes never wait on them, even while one is queued behind a running vacuum. An integration test applies the migration and checks the lock mode, that writes proceed, and that the settings land on both relations.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
[Critical impact] The PR appears safe to merge; no actionable issues were found. SummaryAdds migration
No actionable issues were found. The integration tests were reviewed but not run. waleedlatif1 explicitly acknowledged slower vacuum and loss of cross-worker balancing as the lesser cost of reducing WAL bursts. Reviews (1) · Last reviewed commit: "fix(db): throttle autovacuum on the larg..." · Reviewed by Greptile |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
autovacuum_vacuum_cost_delay = 10/autovacuum_vacuum_cost_limit = 200onembedding,embedding_searchandworkflow_execution_logs, for each table and its TOAST relation. That caps how fast those vacuums dirty pages, and so their WAL rate.ALTER TABLE ... SET (autovacuum params)only updates the catalog and takesSHARE UPDATE EXCLUSIVE. There is no table rewrite. Reads and writes never wait on it, even while it is queued behind a running vacuum or another holder. A running non-wraparound autovacuum is cancelled by the waiting ALTER and restarts later with the new settings. The migrator's existing 5slock_timeoutplus retry covers the case where the ALTER queues behind a long-running conflicting holder.Type of Change
Testing
packages/db/large-table-vacuum-throttle-migration.integration.tsruns against real Postgres 17 and checks that:ShareUpdateExclusiveLock, andrelfilenodeis unchanged (no rewrite);lock_timeoutstill inserts;check:migrationspasses, anddrizzle-kit generatereports no schema changes.Checklist