2010/7/9 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> (2010/07/07 11:31), Robert Haas wrote:
>> On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas<robertmhaas@gmail.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