Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

On Tue, Apr 7, 2015 at 10:15 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:
>
> 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.
>

Ok.

> > > (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));
>

Understood... IMHO the better place to perform this assert is in
"initialize_reloptions".

Thoughts?

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello