From: KaiGai Kohei on
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(a)ak.jp.nec.com>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers