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_4z1j...@mail.gmail.com as diagnosed by Andres Freund. Branch ------ REL9_3_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/2a4b6eed0916a8fdc57b4778ecb1463fe752d369 Modified Files -------------- src/backend/access/heap/heapam.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
