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  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: get_whatever_oid, part 2
Следующее
От: Takahiro Itagaki
Дата:
Сообщение: Re: I: About "Our CLUSTER implementation is pessimal" patch