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 >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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers