Re: Bug? Concurrent COMMENT ON and DROP object

(2010/07/07 11:31), Robert Haas wrote:
> On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>>> Obviously not. We don't need to acquire an AccessExclusiveLock to
>>> comment on an object - just something that will CONFLICT WITH an
>>> AccessExclusiveLock. So, use the same locking rules, perhaps, but
>>> take a much weaker lock, like AccessShareLock.
>>
>> Well, it probably needs to be a self-conflicting lock type, so that
>> two COMMENTs on the same object can't run concurrently. But I agree
>> AccessExclusiveLock is too strong: that implies locking out read-only
>> examination of the object, which we don't want.
>
> Hmm... so, maybe ShareUpdateExclusiveLock? That looks to be the
> weakest thing that is self-conflicting. The others are
> ShareRowExclusiveLock, ExclusiveLock, and AccessExclusiveLock.
>
Is it necessary to confirm existence of the database object being
commented on after we got acquired the lock, isn't it?

Since the logic of AcquireDeletionLock() requires us to provide
argument as object-id form, but we have to translate the object
name into object-id outside of the critical section, so the object
being commented might be already dropped and committed before we
got acquired the lock.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>