On Sat, Aug 1, 2015 at 9:20 PM, Andres Freund wrote: > On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier wrote: >>> 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.
As long as this only applies on master, this may be fine... We could basically pass a LOCKMASK to the multiple layers of tablecmds.c instead of LOCKMODE to track all the locks that need to be taken, and all the relations open during operations. Would it be worth having some routines like relation_multi_[open|close]() as well? Like that: Relation[] relation_multi_open(relation Oid, LOCKMASK): void relation_multi_close(Relation[]); If we do something, we may consider patching as well 9.5, it seems to me that tablecmds.c is broken by assuming that lock hierarchy is monotone in AlterTableGetLockLevel(). -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
