Re: Bug? Concurrent COMMENT ON and DROP object

2010/7/6 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> (2010/07/06 23:33), Tom Lane wrote:
>> Robert Haas<robertmhaas(at)gmail(dot)com>  writes:
>>> 2010/7/6 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>> In the following scenario, we can see orphan comments.
>>
>>> Yeah.  I think the reason we haven't seen any complaints about this
>>> before is that the worst-case scenario is that a comment for a dropped
>>> database object eventually becomes associated with a new database
>>> object.
>>
>> Well, in general there is very little DDL locking for any object type
>> other than tables.  I think the original rationale for that was that
>> most other object types are defined by single catalog entries, so that
>> attempts to update/delete the object would naturally block on changing
>> its tuple anyway.  But between comments and pg_depend entries that seems
>> not particularly true anymore.
>>
>> IIRC there is now some attempt to lock objects of all types during
>> DROP.  Maybe the COMMENT code could acquire a conflicting lock.
>>
> Are you saying AcquireDeletionLock()?
>
> It seems to me fair enough to prevent the problem, although it is declared
> as a static function.

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.

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