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

From: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(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-11 00:15:43
Message-ID: CAFcNs+qmftHe=CSVK-oB=XUsQXA2yBQE1CU3gmbcbvZwFj2xmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 7, 2015 at 10:57 PM, Fabrízio de Royes Mello <
fabriziomello(at)gmail(dot)com> wrote:
>
>
> 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?
>

The attached patch:
- introduce new field "lockmode" to "relopt_gen" struct
- initialize lockmode with ShareUpdateExclusiveLock to autovac settings
- add assert to ensuring that the lock level specified don't conflict with
itself
- add function GetRelOptionsLockLevel to determine the required lock mode
from an option list

Regards,

--
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

Attachment Content-Type Size
alter-table-set-reduce-lock-level-for-autovac-reloptions_v1.patch text/x-diff 12.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message chenhj 2015-04-11 02:02:58 Re: PATCH:do not set Win32 server-side socket buffer size on windows 2012
Previous Message Pavel Stehule 2015-04-10 21:26:25 Re: raw output from copy