From: Alvaro Herrera Date: Thu, 24 Jan 2013 19:04:48 +0000 (-0300) Subject: Redefine HEAP_XMAX_IS_LOCKED_ONLY X-Git-Tag: REL9_3_BETA1~440 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=74ebba84aeb6;p=postgresql 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. --- diff --git a/src/include/access/htup_details.h b/src/include/access/htup_details.h index 6a28d8ed74..cd01ecdba7 100644 --- a/src/include/access/htup_details.h +++ b/src/include/access/htup_details.h @@ -189,14 +189,19 @@ struct HeapTupleHeaderData #define HEAP_XACT_MASK 0xFFF0 /* visibility-related bits */ /* - * A tuple is only locked (i.e. not updated by its Xmax) if it the - * HEAP_XMAX_LOCK_ONLY bit is set. + * A tuple is only locked (i.e. not updated by its Xmax) if the + * HEAP_XMAX_LOCK_ONLY bit is set; or, for pg_upgrade's sake, if the Xmax is + * not a multi and the EXCL_LOCK bit is set. * * See also HeapTupleHeaderIsOnlyLocked, which also checks for a possible * aborted updater transaction. + * + * Beware of multiple evaluations of the argument. */ #define HEAP_XMAX_IS_LOCKED_ONLY(infomask) \ - ((infomask) & HEAP_XMAX_LOCK_ONLY) + (((infomask) & HEAP_XMAX_LOCK_ONLY) || \ + (((infomask) & (HEAP_XMAX_IS_MULTI | HEAP_LOCK_MASK)) == HEAP_XMAX_EXCL_LOCK)) + /* * Use these to test whether a particular lock is applied to a tuple */