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: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: 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-14 20:07:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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().

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-11-14 20:19:01
Subject: Re: strict aliasing (was: const correctness)
Previous:From: Thom BrownDate: 2011-11-14 20:04:26
Subject: Re: patch: CHECK FUNCTION statement

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