From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |
Date: | 2015-08-01 12:20:56 |
Message-ID: | 05AEB265-372D-463F-8A80-04886E362856@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>On Sat, Aug 1, 2015 at 5:00 AM, Alvaro Herrera
><alvherre(at)2ndquadrant(dot)com> wrote:
>> Fabrízio de Royes Mello wrote:
>>
>>> In this patch I didn't change all lockmode comparison places
>previous
>>> pointed by you, but I can change it maybe adding other method called
>>> LockModeIsValid(lockmode) to do the comparison "lockmode >= NoLock
>&&
>>> lockmode < MAX_LOCKMODES" used in many places.
>>
>> I don't like this. Is it possible to write these comparisons in
>terms
>> of what they conflict with? I think there are two main cases in the
>> existing code:
>>
>> 1. "is this lock mode valid" (sounds reasonable)
>> 2. "can this be acquired in hot standby" (not so much, but makes
>> sense.)
>>
>> and now we have your third thing, "what is the strongest of these two
>> locks".
>
>The third method already exists in tablecmds.c:
> /*
> * Take the greatest lockmode from any subcommand
> */
> if (cmd_lockmode > lockmode)
> lockmode = cmd_lockmode;
>
>> For instance, if you told me to choose between ShareLock and
>> ShareUpdateExclusiveLock I wouldn't know which one is strongest. I
>> don't it's sensible to have the "lock mode compare" primitive
>honestly.
>> I don't have any great ideas to offer ATM sadly.
>
>Yes, the thing is that lowering the lock levels is good for
>concurrency, but the non-monotony of the lock levels makes it
>impossible to choose an intermediate state correctly.
How about simply acquiring all the locks individually of they're different types? These few acquisitions won't matter.
---
Please excuse brevity and formatting - I am writing this on my mobile phone.
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2015-08-01 13:09:50 | Re: [DESIGN] ParallelAppend |
Previous Message | Michael Paquier | 2015-08-01 12:17:24 | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |