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
|
Список | 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 по дате отправления: