Re: Bug? Concurrent COMMENT ON and DROP object

2010/7/9 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> (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.

Yep. I'm going to work up a patch for this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company