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 6 Jul 2010 22:31 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. -- 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
From: Alvaro Herrera on 6 Jul 2010 22:59 Excerpts from Robert Haas's message of mar jul 06 22:31:40 -0400 2010: > 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? So COMMENT ON will conflict with (auto)vacuum? Seems a bit weird ... -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 7 Jul 2010 18:50 On Tue, Jul 6, 2010 at 10:59 PM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > Excerpts from Robert Haas's message of mar jul 06 22:31:40 -0400 2010: >> 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? > > So COMMENT ON will conflict with (auto)vacuum? �Seems a bit weird ... Well, I'm open to suggestions... I doubt we want to create a new lock level just 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
From: Tom Lane on 7 Jul 2010 20:29 Robert Haas <robertmhaas(a)gmail.com> writes: > On Tue, Jul 6, 2010 at 10:59 PM, Alvaro Herrera > <alvherre(a)commandprompt.com> wrote: >> Excerpts from Robert Haas's message of mar jul 06 22:31:40 -0400 2010: >>> Hmm... so, maybe ShareUpdateExclusiveLock? >> >> So COMMENT ON will conflict with (auto)vacuum? �Seems a bit weird ... > Well, I'm open to suggestions... I doubt we want to create a new lock > level just for this. [ shrug... ] COMMENT ON is DDL, and most forms of DDL will conflict with vacuum. I can't get excited about that complaint. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 9 Jul 2010 00:56
(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. Thanks, -- KaiGai Kohei <kaigai(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |