Skip site navigation (1) Skip section navigation (2)

Bug? Concurrent COMMENT ON and DROP object

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Bug? Concurrent COMMENT ON and DROP object
Date: 2010-07-06 07:22:14
Message-ID: 4C32D9A6.9090500@ak.jp.nec.com (view raw or flat)
Thread:
Lists: 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(at)ak(dot)jp(dot)nec(dot)com>

Responses

pgsql-hackers by date

Next:From: Takahiro ItagakiDate: 2010-07-06 07:52:27
Subject: Re: I: About "Our CLUSTER implementation is pessimal" patch
Previous:From: KaiGai KoheiDate: 2010-07-06 03:13:06
Subject: Re: get_whatever_oid, part 2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group