Fix broken Assert() introduced by 8e9a16ab8f7f0e58

Don't assert MultiXactIdIsRunning if the multi came from a tuple that
had been share-locked and later copied over to the new cluster by
pg_upgrade.  Doing that causes an error to be raised unnecessarily:
MultiXactIdIsRunning is not open to the possibility that its argument
came from a pg_upgraded tuple, and all its other callers are already
checking; but such multis cannot, obviously, have transactions still
running, so the assert is pointless.

Noticed while investigating the bogus pg_multixact/offsets/0000 file
left over by pg_upgrade, as reported by Andres Freund in
http://www.postgresql.org/message-id/20140530121631.GE25431@alap3.anarazel.de

Backpatch to 9.3, as the commit that introduced the buglet.

diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index f8bed1969268a079ab6f6891eaf9e28078d35c0e..6861ae0a7f2e0191a6234966b5fe621e3fc59b1a 100644 (file)
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -5518,8 +5518,14 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
                 * was a locker only, it can be removed without any further
                 * consideration; but if it contained an update, we might need to
                 * preserve it.
+                *
+                * Don't assert MultiXactIdIsRunning if the multi came from a
+                * pg_upgrade'd share-locked tuple, though, as doing that causes an
+                * error to be raised unnecessarily.
                 */
-               Assert(!MultiXactIdIsRunning(multi));
+               Assert((!(t_infomask & HEAP_LOCK_MASK) &&
+                               HEAP_XMAX_IS_LOCKED_ONLY(t_infomask)) ||
+                          !MultiXactIdIsRunning(multi));
                if (HEAP_XMAX_IS_LOCKED_ONLY(t_infomask))
                {
                        *flags |= FRM_INVALIDATE_XMAX;