summaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistutil.c
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2013-01-24 16:04:48 -0300
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2013-01-24 16:10:02 -0300
commit74ebba84aeb6b0e6320f9b992527715f7e2ace8e (patch)
tree01c391b0c86e01bb7c2319b6fa9896b72f4d711f /src/backend/access/gist/gistutil.c
parent34da700405737be055d1b3d310af23a98da72e8e (diff)
downloadpostgresql-74ebba84aeb6b0e6320f9b992527715f7e2ace8e.tar.gz
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.
Diffstat (limited to 'src/backend/access/gist/gistutil.c')
0 files changed, 0 insertions, 0 deletions