]> granicus.if.org Git - postgresql/commit
Redefine HEAP_XMAX_IS_LOCKED_ONLY
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 24 Jan 2013 19:04:48 +0000 (16:04 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 24 Jan 2013 19:10:02 +0000 (16:10 -0300)
commit74ebba84aeb6b0e6320f9b992527715f7e2ace8e
tree01c391b0c86e01bb7c2319b6fa9896b72f4d711f
parent34da700405737be055d1b3d310af23a98da72e8e
Redefine HEAP_XMAX_IS_LOCKED_ONLY

Tuples marked SELECT FOR UPDATE in a cluster that's later processed by
pg_upgrade would have a different infomask bit pattern than those
produced by 9.3dev; that bit pattern was being seen as "dead" by HEAD
(because they would fail the "is this tuple locked" test, and so the
visibility rules would thing they're updated, even though there's no
HEAP_UPDATED version of them).  In other words, some rows could silently
disappear after pg_upgrade.

With this new definition, those tuples become visible again.

This is breakage resulting from my commit 0ac5ad5134.
src/include/access/htup_details.h