Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Date
Msg-id CAP7QgmnSz2FQ8gYbD24fv_mjGUVCovaCYJJJcf=KWrDuoty5RA@mail.gmail.com
Whole thread Raw
In response to Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
List pgsql-hackers
On Sat, Jan 14, 2012 at 6:48 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Jan 14, 2012 at 5:25 AM, Hitoshi Harada <umi.tanuki@gmail.com> wrote:
>> The patch looks ok, though I wonder if we could have a way to release
>> the lock on namespace much before the end of transaction.
>
> Well, that wold kind of miss the point, wouldn't it?  I mean, the race
> is that the process dropping the schema might not see the newly
> created object.  The only way to prevent that is to hold some sort of
> lock until the newly created object is visible, which doesn't happen
> until commit.
>
>> I know it's a limited situation, though. Maybe the right way would be
>> to check the namespace at the end of the transaction if any object is
>> created, rather than locking it.
>
> And then what?  If you find that you created an object in a namespace
> that's been subsequently dropped, what do you do about that?  As far
> as I can see, your own really choice would be to roll back the
> transaction that uncovers this problem, which is likely to produce
> more rollbacks than just letting the deadlock detector sort it out.

Right. I thought this patch introduced lock on schema in SELECT, but
actually we'd been locking schema with SELECT since before the patch.
So the behavior becomes consistent (between SELECT and CREATE) now
with it. And I agree that my insist is pointless after looking more.

Thanks,
--
Hitoshi Harada


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Patch to allow users to kill their own queries
Next
From: Andrew Dunstan
Date:
Subject: Re: JSON for PG 9.2