Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit b277057

Browse files
committed
Fix broken Assert() introduced by 8e9a16a
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.
1 parent 1147035 commit b277057

File tree

1 file changed

+7
-1
lines changed

1 file changed

+7
-1
lines changed

src/backend/access/heap/heapam.c

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5518,8 +5518,14 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask,
55185518
* was a locker only, it can be removed without any further
55195519
* consideration; but if it contained an update, we might need to
55205520
* preserve it.
5521+
*
5522+
* Don't assert MultiXactIdIsRunning if the multi came from a
5523+
* pg_upgrade'd share-locked tuple, though, as doing that causes an
5524+
* error to be raised unnecessarily.
55215525
*/
5522-
Assert(!MultiXactIdIsRunning(multi));
5526+
Assert((!(t_infomask & HEAP_LOCK_MASK) &&
5527+
HEAP_XMAX_IS_LOCKED_ONLY(t_infomask)) ||
5528+
!MultiXactIdIsRunning(multi));
55235529
if (HEAP_XMAX_IS_LOCKED_ONLY(t_infomask))
55245530
{
55255531
*flags |= FRM_INVALIDATE_XMAX;

0 commit comments

Comments
 (0)