Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

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.

Cheers,

--
fdr