Bug? Concurrent COMMENT ON and DROP object
in [PgSql]
|
Prev: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch
Next: pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.
From: Robert Haas on 9 Jul 2010 07:48 2010/7/9 KaiGai Kohei <kaigai(a)ak.jp.nec.com>: > (2010/07/07 11:31), Robert Haas wrote: >> On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane<tgl(a)sss.pgh.pa.us> �wrote: >>> Robert Haas<robertmhaas(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |