]> granicus.if.org Git - postgresql/commit
Compare Xmin to previous Xmax when locking an update chain
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 27 Nov 2013 20:49:12 +0000 (17:49 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 28 Nov 2013 15:00:12 +0000 (12:00 -0300)
commite4828e9ccba731178dd77aed078db7ceb0e1e8d1
treea145e5f5c9360b1fad8dc33eb10373766f12961b
parentc235a6a589bbd0a24e54fdb0df28979c9fb09463
Compare Xmin to previous Xmax when locking an update chain

Not doing so causes us to traverse an update chain that has been broken
by concurrent page pruning.  All other code that traverses update chains
uses this check as one of the cases in which to stop iterating, so
replicate it here too.  Failure to do so leads to erroneous CLOG,
subtrans or multixact lookups.

Per discussion following the bug report by J Smith in
CADFUPgc5bmtv-yg9znxV-vcfkb+JPRqs7m2OesQXaM_4Z1JpdQ@mail.gmail.com
as diagnosed by Andres Freund.
src/backend/access/heap/heapam.c