Alvaro Herrera wrote:
> Improve concurrency of foreign key locking
I noticed a bug in visibility routines when pg_upgrade is involved:
tuples marked FOR UPDATE in the old cluster (i.e. HEAP_XMAX_INVALID not
set, HEAP_XMAX_EXCL_LOCK set, HEAP_XMAX_IS_MULTI not set) are invisible
(dead) on the new cluster. I had defined the HEAP_XMAX_IS_LOCKED_ONLY
thusly:
#define HEAP_XMAX_IS_LOCKED_ONLY(infomask) \((infomask) & HEAP_XMAX_LOCK_ONLY)
but this doesn't work for the reason stated above. The fix is to
redefine the macro like this:
/** 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
checksfor 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_IS_MULTI
|HEAP_LOCK_MASK)) == HEAP_XMAX_EXCL_LOCK))
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services