From 988ffc30637ce2b7c4ff984513f4695372602ce2 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Tue, 15 Feb 2022 15:16:19 -0800 Subject: [PATCH] Update "don't truncate with failsafe" rationale. There is a very good (though non-obvious) reason to avoid relation truncation during a VACUUM that has triggered the failsafe mechanism, which was missed before now. Update related comments, so this isn't forgotten. Reported-By: John Naylor Discussion: https://postgr.es/m/CAFBsxsFiMPxQ-dHZ8tOgktn=+ffeJT3+GinZ4zdOGbmAnCYadA@mail.gmail.com --- src/backend/access/heap/vacuumlazy.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c index 9c88b9bd71..242511a235 100644 --- a/src/backend/access/heap/vacuumlazy.c +++ b/src/backend/access/heap/vacuumlazy.c @@ -2793,8 +2793,13 @@ lazy_cleanup_one_index(Relation indrel, IndexBulkDeleteResult *istat, * an AccessExclusive lock must be replayed on any hot standby, where it can * be particularly disruptive. * - * Also don't attempt it if wraparound failsafe is in effect. It's hard to - * predict how long lazy_truncate_heap will take. Don't take any chances. + * Also don't attempt it if wraparound failsafe is in effect. The entire + * system might be refusing to allocate new XIDs at this point. The system + * definitely won't return to normal unless and until VACUUM actually advances + * the oldest relfrozenxid -- which hasn't happened for target rel just yet. + * If lazy_truncate_heap attempted to acquire an AccessExclusiveLock to + * truncate the table under these circumstances, an XID exhaustion error might + * make it impossible for VACUUM to fix the underlying XID exhaustion problem. * There is very little chance of truncation working out when the failsafe is * in effect in any case. lazy_scan_prune makes the optimistic assumption * that any LP_DEAD items it encounters will always be LP_UNUSED by the time -- 2.39.5