]> granicus.if.org Git - postgresql/commit
Remove special case for xmin == xmax in HeapTupleSatisfiesVacuum().
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 29 Apr 2011 20:30:02 +0000 (16:30 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 29 Apr 2011 20:30:02 +0000 (16:30 -0400)
commit735d88e60e634b4563e66b3c200019fd1e556a42
tree854063628c9f8ddd791f1ec53e82389e269b8976
parent67abb9598fdf4231b8e1a9f433bbcf1ee7fe3d68
Remove special case for xmin == xmax in HeapTupleSatisfiesVacuum().

VACUUM was willing to remove a committed-dead tuple immediately if it was
deleted by the same transaction that inserted it.  The idea is that such a
tuple could never have been visible to any other transaction, so we don't
need to keep it around to satisfy MVCC snapshots.  However, there was
already an exception for tuples that are part of an update chain, and this
exception created a problem: we might remove TOAST tuples (which are never
part of an update chain) while their parent tuple stayed around (if it was
part of an update chain).  This didn't pose a problem for most things,
since the parent tuple is indeed dead: no snapshot will ever consider it
visible.  But MVCC-safe CLUSTER had a problem, since it will try to copy
RECENTLY_DEAD tuples to the new table.  It then has to copy their TOAST
data too, and would fail if VACUUM had already removed the toast tuples.

Easiest fix is to get rid of the special case for xmin == xmax.  This may
delay reclaiming dead space for a little bit in some cases, but it's by far
the most reliable way to fix the issue.

Per bug #5998 from Mark Reid.  Back-patch to 8.3, which is the oldest
version with MVCC-safe CLUSTER.
src/backend/utils/time/tqual.c