On Mon, Nov 14, 2011 at 12:07 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Nov 14, 2011 at 2:26 PM, Alvaro Herrera > <alvhe...@commandprompt.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. Cheers, -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
