Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
От | Alvaro Herrera |
---|---|
Тема | Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers |
Дата | |
Msg-id | 1321298707-sup-8007@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
|
Список | 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
В списке pgsql-hackers по дате отправления: