Re: pgsql: Fix a couple of bugs in MultiXactId freezing - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Date
Msg-id 20131212213942.GB12902@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: pgsql: Fix a couple of bugs in MultiXactId freezing  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pgsql: Fix a couple of bugs in MultiXactId freezing
List pgsql-hackers
Alvaro Herrera wrote:

> One last thing (I hope).  It's not real easy to disable this check,
> because it actually lives in GetNewMultiXactId.  It would uglify the API
> a lot if we were to pass a flag down two layers of routines; and moving
> it to higher-level routines doesn't seem all that appropriate either.
> I'm thinking we can have a new flag in MyPgXact->vacuumFlags, so
> heap_prepare_freeze_tuple does this:
> 
>         PG_TRY();
>         {
>             /* set flag to let multixact.c know what we're doing */
>             MyPgXact->vacuumFlags |= PROC_FREEZING_MULTI;
>             newxmax = FreezeMultiXactId(xid, tuple->t_infomask,
>                                         cutoff_xid, cutoff_multi, &flags);
>         }

Uhm, actually we don't need a PG_TRY block at all for this to work: we
can rely on the flag being reset at transaction abort, if anything wrong
happens and we lose control.  So just set the flag, call
FreezeMultiXactId, reset flag.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: Extra functionality to createuser
Next
From: Christophe Pettus
Date:
Subject: "stuck spinlock"