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 <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
