postgres.git / summary / log / commit / refs

commit    b2770576486265c2ce35b64e875028672a3bb7b5
Author:   Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:     Fri Jun 27 18:43:39 2014 +0000
First released in: 9.5.0, 9.3.5, 9.4.0

    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.


src/backend/access/heap/heapam.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index f8bed196926..6861ae0a7f2 100644 --- 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; [parent: 1147035203a4]