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

Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Daniel Farina <daniel(at)heroku(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Nikhil Sontakke <nikkhils(at)gmail(dot)com>, Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Date: 2012-01-15 16:03:30
Message-ID: CAP7QgmnSz2FQ8gYbD24fv_mjGUVCovaCYJJJcf=KWrDuoty5RA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Jan 14, 2012 at 6:48 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Jan 14, 2012 at 5:25 AM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2012-01-15 16:08:05
Subject: Re: JSON for PG 9.2
Previous:From: Magnus HaganderDate: 2012-01-15 14:41:02
Subject: Re: Patch to allow users to kill their own queries

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