On Tue, Apr 7, 2015 at 10:57 PM, Fabrízio de Royes Mello <
fabriziomello@gmail.com> wrote:
>
>
> On Tue, Apr 7, 2015 at 10:15 PM, Alvaro Herrera <
alvherre@2ndquadrant.com> wrote:
> >
> > Fabrízio de Royes Mello wrote:
> > > On Mon, Apr 6, 2015 at 12:53 AM, Alvaro Herrera <
alvherre@2ndquadrant.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?
>