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

Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Hitoshi Harada <umi(dot)tanuki(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-16 14:53:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Jan 15, 2012 at 11:03 AM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
> 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.

No, we lock the table with SELECT, not the schema.  This doesn't add
any additional locking for DML: nor is any needed, AFAICS.

> So the behavior becomes consistent (between SELECT and CREATE) now
> with it. And I agree that my insist is pointless after looking more.

OK.  Thanks for your review.

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2012-01-16 15:23:52
Subject: inconsistent comparison of CHECK constraints
Previous:From: Alvaro HerreraDate: 2012-01-16 14:44:01
Subject: Re: age(xid) on hot standby

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