2010/7/9 KaiGai Kohei <kai...@ak.jp.nec.com>: > (2010/07/07 11:31), Robert Haas wrote: >> On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: >>> Robert Haas<robertmh...@gmail.com> writes: >>>> Obviously not. We don't need to acquire an AccessExclusiveLock to >>>> comment on an object - just something that will CONFLICT WITH an >>>> AccessExclusiveLock. So, use the same locking rules, perhaps, but >>>> take a much weaker lock, like AccessShareLock. >>> >>> Well, it probably needs to be a self-conflicting lock type, so that >>> two COMMENTs on the same object can't run concurrently. But I agree >>> AccessExclusiveLock is too strong: that implies locking out read-only >>> examination of the object, which we don't want. >> >> Hmm... so, maybe ShareUpdateExclusiveLock? That looks to be the >> weakest thing that is self-conflicting. The others are >> ShareRowExclusiveLock, ExclusiveLock, and AccessExclusiveLock. >> > Is it necessary to confirm existence of the database object being > commented on after we got acquired the lock, isn't it? > > Since the logic of AcquireDeletionLock() requires us to provide > argument as object-id form, but we have to translate the object > name into object-id outside of the critical section, so the object > being commented might be already dropped and committed before we > got acquired the lock.
Yep. I'm going to work up a patch for this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
