Re: Bug? Concurrent COMMENT ON and DROP object

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bug? Concurrent COMMENT ON and DROP object
Дата
Msg-id 27531.1278426798@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bug? Concurrent COMMENT ON and DROP object  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Bug? Concurrent COMMENT ON and DROP object  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 2010/7/6 KaiGai Kohei <kaigai@ak.jp.nec.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.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.