On Tue, Aug 4, 2015 at 2:43 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Michael Paquier wrote:
>
>> As mentioned in the thread related to lowering locks of autovacuum
>> reloptions in ALTER TABLE SET
>> (http://www.postgresql.org/message-id/CAFcNs+oX7jVENC_3i54fDQ3ibmOGmknc2tMevdSmvojbSXGbGg@mail.gmail.com),
>> I have noticed the following code in
>> AlterTableGetLockLevel@tablecmds.c:
>> /*
>> * Take the greatest lockmode from any subcommand
>> */
>> if (cmd_lockmode > lockmode)
>> lockmode = cmd_lockmode;
>>
>> The thing is that, as mentioned by Alvaro and Andres on this thread,
>> we have no guarantee that the different relation locks compared have a
>> monotone hierarchy and we may finish by taking a lock that does not
>> behave as you would like to.
>
> Maybe the solution to this is to add the concept of "addition" of two
> lock modes, where the result is another lock mode that conflicts with
> any lock that would conflict with either of the two operand lock modes.
> For instance, if you add a lock mode to itself, you get the same lock
> mode; if you "add" anything to AccessExclusive, you get AccessExclusive;
> if you "add" anything to AccessShare, you end up with that other lock
> mode. The most interesting case in our current lock table is if you
> "add" ShareUpdateExclusive to Share, where you end up with
> ShareRowExclusive. In essence, holding the result of that operation is
> the same as holding both locks, which AFAICS is the behavior we want.
That's commutative, as this is basically looking at the conflict table
to get the union of the bits to indicate what are all the locks
conflicting with lock A and lock B, and then we select the lock on the
table that includes the whole union, with a minimum number of them.
Now, let's take for example this case with locks A, B, C, D:
- Lock A conflicts with ACD
- B with BCD
- C with itself
- D with itself
What would you choose as a result of add(C,D)? A or B? Or the super
lock conflicting with all of them?
--
Michael
