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

Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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: 2011-11-29 08:37:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Nov 14, 2011 at 12:07 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Nov 14, 2011 at 2:26 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>> Excerpts from Robert Haas's message of lun nov 14 15:56:43 -0300 2011:
>>> Well, it looks to me like there are three different places that we
>>> need to nail down: RangeVarGetAndCheckCreationNamespace() is used for
>>> relations (except that a few places call RangeVarGetCreationNamespace
>>> directly, which means my previous patch probably needs some tweaking
>>> before commit), QualifiedNameGetCreationNamespace() is used for pretty
>>> much all other schema-qualified objects, and LookupCreationNamespace()
>>> is used for ALTER BLAH SET SCHEMA (which I think has a problem when
>>> you rename an object into a schema that is concurrently being
>>> dropped).
>>> I'm fairly unhappy with the idea of modifying a function that is
>>> described as doing a "get" or "lookup" to have the side effect of
>>> "locking something".  So probably some renaming or refactoring is in
>>> order here.  It seems like we're duplicating almost identical logic in
>>> an awful lot of places in namespace.c.
>> So RangeVarGetCheckAndLockCreationNamespace(), uh?  Pity you can't
>> stick a comma in there.
> Yeah, really.  :-)
> Actually, I think that one could probably stay as-is.  "Check" implies
> that there's something else going on besides just a lookup, and we
> can't go nuts with it.  I'm more concerned about
> QualifiedNameGetCreationNamespace() and LookupCreationNamespace().

Hmm, just to prod this thread: has any fix for this been committed?
After Nikhil confirmed that this bug could cause pg_dump to not be
able to operate without direct catalog surgery I have encountered this
bug (and treated its symptoms in the same manner) twice.  I tried to
do my homework in a backbranch, but am not seeing anything beaming out
at me.



In response to


pgsql-hackers by date

Next:From: Albe LaurenzDate: 2011-11-29 09:25:53
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Previous:From: Stefan KellerDate: 2011-11-29 08:32:48
Subject: Re: odbc_fdw

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