On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier <michael.paquier@gmail.com> wrote:
>On Sat, Aug 1, 2015 at 5:00 AM, Alvaro Herrera
><alvherre@2ndquadrant.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.