Bug? Concurrent COMMENT ON and DROP object
От | KaiGai Kohei |
---|---|
Тема | Bug? Concurrent COMMENT ON and DROP object |
Дата | |
Msg-id | 4C32D9A6.9090500@ak.jp.nec.com обсуждение исходный текст |
Ответы |
Re: Bug? Concurrent COMMENT ON and DROP object
|
Список | pgsql-hackers |
In the following scenario, we can see orphan comments. session.1 session.2 ---------------------- ---------------------- 1: CREATE TYPE my_typ AS (a int, b text); 2: BEGIN; 3: COMMENT ON TYPE my_typ IS 'testtest'; 4: DROP TYPE my_typ; 5: COMMIT; SELECT * FROM pg_description WHERE description = 'testtest'; objoid | classoid | objsubid | description --------+----------+----------+------------- 16393 | 1247 | 0 | testtest (1 row) ---------------------- ---------------------- The CommentRelation() has the following code: | static void | CommentRelation(int objtype, List *relname, char *comment) | { | Relation relation; | RangeVar *tgtrel; | | tgtrel = makeRangeVarFromNameList(relname); | | /* | * Open the relation. We do this mainly to acquire a lock that ensures no | * one else drops the relation before we commit. (If they did, they'd | * fail to remove the entry we are about to make in pg_description.) | */ | relation = relation_openrv(tgtrel, AccessShareLock); | : | : | /* Done, but hold lock until commit */ | relation_close(relation, NoLock); | } It says the purpose of the relation_openrv() to acquire a lock that ensures no one else drops the relation before we commit. So, I was blocked when I tried to comment on the table which was already dropped in another session but uncommited yet. However, it is not a problem limited to relations. For example, we need to acquire a lock on the pg_type catalog using 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? -- KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: