diff options
| author | Peter Geoghegan <pg@bowt.ie> | 2022-02-15 15:16:19 -0800 |
|---|---|---|
| committer | Peter Geoghegan <pg@bowt.ie> | 2022-02-15 15:16:19 -0800 |
| commit | 988ffc30637ce2b7c4ff984513f4695372602ce2 (patch) | |
| tree | fcf88f578b64ae176521e746162d79aec5b99386 | |
| parent | 3b0ee7f583dc347c4aecb57d35830d2f99956e5c (diff) | |
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 <john.naylor@enterprisedb.com>
Discussion: https://postgr.es/m/CAFBsxsFiMPxQ-dHZ8tOgktn=+ffeJT3+GinZ4zdOGbmAnCYadA@mail.gmail.com
| -rw-r--r-- | src/backend/access/heap/vacuumlazy.c | 9 |
1 files changed, 7 insertions, 2 deletions
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c index 9c88b9bd71a..242511a235f 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 |