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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
