On Wed, Aug 5, 2015 at 2:15 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Andres Freund wrote:
>> On 2015-08-03 14:15:27 +0900, Michael Paquier wrote:
>
>> > 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.
>>
>> This sounds far too complicated to me. Just LockRelationOid() the
>> relation with the appropriate level everytime you pass through the
>> function?
>
> That opens up for lock escalation and deadlocks, doesn't it? You are
> probably thinking that it's okay to ignore those but I don't necessarily
> agree with that.
Yes, I think so as long as we would try to take multiple locks... And
we go back to the lock hierarchy then, because there is no way to
define in some cases which lock is strictly stronger than the other.
Honestly I think that we should go with the version Fabrizio doing the
lock comparison, with a assert safeguard in AlterTableGetLockLevel.
The logic would get broken if ALTER TABLE begins to use a lock level
that cannot be ordered according to the others, but that's not the
case now.
--
Michael
