(2010/07/06 23:33), Tom Lane wrote: > Robert Haas<robertmh...@gmail.com> writes: >> 2010/7/6 KaiGai Kohei<kai...@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. > 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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
