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
