Comments
Hacker News
The byte by byte view makes the failure mode people run into easier to explain. VACUUM can never remove a tuple whose xmax is newer than the oldest snapshot still open, so one forgotten idle transaction or an abandoned replication slot pins that horizon and every autovacuum pass does a full scan while reclaiming almost nothing. When a table keeps bloating even though autovacuum looks healthy, backend_xmin in pg_stat_activity and xmin in pg_replication_slots are the first two places to check.
by haeseong
Really nice explanation! One note: pg_repack is an extension, but Postgres 19 will get a built-in REPACK command: https://www.postgresql.org/docs/19/sql-repack.html .
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- The byte by byte view makes the failure mode people run into easier to explain. VACUUM can never remove a tuple whose xmax is newer than the oldest snapshot still open, so one forgotten idle transaction or an abandoned replication slot pins that horizon and every autovacuum pass does a full scan while reclaiming almost nothing. When a table keeps bloating even though autovacuum looks healthy, backend_xmin in pg_stat_activity and xmin in pg_replication_slots are the first two places to check.by haeseong
- Really nice explanation! One note: pg_repack is an extension, but Postgres 19 will get a built-in REPACK command: https://www.postgresql.org/docs/19/sql-repack.html .