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

Re: Bug? Concurrent COMMENT ON and DROP object

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bug? Concurrent COMMENT ON and DROP object
Date: 2010-07-06 13:45:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

Robert Haas
The Enterprise Postgres Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-07-06 14:08:21
Subject: Re: t_self as system column
Previous:From: Robert HaasDate: 2010-07-06 13:25:03
Subject: Re: get_whatever_oid, part 1: object types with unqualifed names

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