aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/basics.source
diff options
context:
space:
mode:
authorMelanie Plageman <melanieplageman@gmail.com>2024-07-19 10:44:36 -0400
committerMelanie Plageman <melanieplageman@gmail.com>2024-07-19 12:11:41 -0400
commit06bf404cd07bd82f08a3000d5977080f945e70ca (patch)
tree2b5bb24e13b814f901be8933445c2dc9d3d81933 /src/tutorial/basics.source
parentd97f2ee50e49046a984665fb72fa14a06bd58435 (diff)
downloadpostgresql-06bf404cd07bd82f08a3000d5977080f945e70ca.tar.gz
postgresql-06bf404cd07bd82f08a3000d5977080f945e70ca.zip
Ensure vacuum removes all visibly dead tuples older than OldestXmin
If vacuum fails to remove a tuple with xmax older than VacuumCutoffs->OldestXmin and younger than GlobalVisState->maybe_needed, it will loop infinitely in lazy_scan_prune(), which compares tuples' visibility information to OldestXmin. Starting in version 14, which uses GlobalVisState for visibility testing during pruning, it is possible for GlobalVisState->maybe_needed to precede OldestXmin if maybe_needed is forced to go backward while vacuum is running. This can happen if a disconnected standby with a running transaction older than VacuumCutoffs->OldestXmin reconnects to the primary after vacuum initially calculates GlobalVisState and OldestXmin. Fix this by having vacuum always remove tuples older than OldestXmin during pruning. This is okay because the standby won't replay the tuple removal until the tuple is removable. Thus, the worst that can happen is a recovery conflict. Fixes BUG# 17257 Back-patched in versions 14-17 Author: Melanie Plageman Reviewed-by: Noah Misch, Peter Geoghegan, Robert Haas, Andres Freund, and Heikki Linnakangas Discussion: https://postgr.es/m/CAAKRu_Y_NJzF4-8gzTTeaOuUL3CcGoXPjXcAHbTTygT8AyVqag%40mail.gmail.com
Diffstat (limited to 'src/tutorial/basics.source')
0 files changed, 0 insertions, 0 deletions