Re: Bug? Concurrent COMMENT ON and DROP object

(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.

>>> For example, we need to acquire a lock on the pg_type catalog when we
>>> try to comment on any type object. Perhaps, I think LockRelationOid()
>>> should be injected at head of the CommentType() in this case.
>>>
>>> Any comments?
>
>> A more fine-grained lock would be preferable,
>
> s/preferable/essential/. This cure would be *far* worse than the
> disease. Can you say "deadlock"?
>
> regards, tom lane
>

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