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-07 23:52:07
Message-ID: CAFcNs+o0R8WJUBz6uP_-r5UGKmfNivj7GBfmVq+Ten=DKu0oFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-04-08 00:59:26 Tuple visibility within a single XID
Previous Message Qingqing Zhou 2015-04-07 23:15:21 Re: rare avl shutdown slowness (related to signal handling)