Re: pgsql: Fix a couple of bugs in MultiXactId freezing

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Date: 2013-12-12 21:39:43
Message-ID: 20131212213942.GB12902@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2013-12-12 22:40:59 Re: pgsql: Fix a couple of bugs in MultiXactId freezing
Previous Message Alvaro Herrera 2013-12-12 21:24:34 Re: pgsql: Fix a couple of bugs in MultiXactId freezing

Browse pgsql-hackers by date

  From Date Subject
Next Message Christophe Pettus 2013-12-12 21:50:06 "stuck spinlock"
Previous Message Christopher Browne 2013-12-12 21:38:17 Re: Extra functionality to createuser