On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier 
<michael.paqu...@gmail.com> wrote:
>On Sat, Aug 1, 2015 at 5:00 AM, Alvaro Herrera
><alvhe...@2ndquadrant.com> wrote:
>> Fabrízio de Royes Mello wrote:
>>> In this patch I didn't change all lockmode comparison places
>>> 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
>> 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
>> 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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to