From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |
Date: | 2015-04-08 01:15:32 |
Message-ID: | 20150408011532.GP4369@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fabrízio de Royes Mello wrote:
> On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
> wrote:
> >
> > Fabrízio de Royes Mello wrote:
> >
> > > Ok guys. The attached patch refactor the reloptions adding a new field
> > > "lockmode" in "relopt_gen" struct and a new method to determine the
> > > required lock level from an option list.
> > >
> > > We need determine the appropriate lock level for each reloption:
> >
> > I don't think AccessShareLock is appropriate for any option change. You
> > should be using a lock level that's self-conflicting, as a minimum
> > requirement, to avoid two processes changing the value concurrently.
>
> What locklevel do you suggest? Maybe ShareLock?
ShareUpdateExclusive probably. ShareLock doesn't conflict with itself.
> > (I would probably go as far as ensuring that the lock level specified in
> > the table DoLockModesConflict() with itself in an Assert somewhere.)
>
> If I understood this is to check if the locklevel of the reloption list
> don't conflict one each other, is it?
I mean
Assert(DoLockModesConflict(relopt_gen->locklevel, relopt_gen->locklevel));
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-04-08 01:21:27 | Re: New error code to track unsupported contexts |
Previous Message | Peter Geoghegan | 2015-04-08 01:11:35 | Re: Tuple visibility within a single XID |