Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Alvaro Herrera <alvherre@commandprompt.com>
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nikhil Sontakke <nikkhils@gmail.com>, Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-11-14T19:26:04Z
Lists: pgsql-hackers
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. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support