Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Still, it's an interesting alternative. Comments anyone?
> SelfExclusiveLock is clear and can't be confused with other lock types.
It could possibly be made a little less dangerous if "SelfExclusiveLock"
were defined to conflict with itself and AccessExclusiveLock (and
nothing else). That would at least mean that holding SelfExclusiveLock
would guarantee the table not go away under you; so there might be
scenarios where holding just that lock would make sense.
Still, I'm not sure that this lock type is as flexible as it seems at
first glance. What you'd probably really want it to do is guarantee
that no other instance of your same operation (whatever it is) is
running, and then you'd acquire another lock type to lock out other
operations that you couldn't run in parallel with. Sounds great,
except there'd only be one SelfExclusiveLock per table. So, for
example, your operation would conflict with VACUUM whether you wanted
it to or not.
Between that and the need-two-locks hazards, I'm unconvinced that this
is a better idea.
regards, tom lane