Re: Bug? Concurrent COMMENT ON and DROP object

2010/7/6 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> In the following scenario, we can see orphan comments.

Yeah. I think the reason we haven't seen any complaints about this
before is that the worst-case scenario is that a comment for a dropped
database object eventually becomes associated with a new database
object. But that can only happen if the OID counter wraps around and
then OID then gets reused for another object of the same type, and
even then you might easily fail to notice. Still, it would be nice to
clean this up.

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

A more fine-grained lock would be preferable, if we can manage it.
Can we just lock the relevant pg_type tuple, rather than the whole
relation?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company