Re: Re: 8.3.5: Types with typnamespace pointing at non-existent pg_namespace oid - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Re: 8.3.5: Types with typnamespace pointing at non-existent pg_namespace oid
Date
Msg-id 1652.1298393670@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.3.5: Types with typnamespace pointing at non-existent pg_namespace oid  (Daniel Farina <daniel@heroku.com>)
Responses Re: Re: 8.3.5: Types with typnamespace pointing at non-existent pg_namespace oid  (Daniel Farina <daniel@heroku.com>)
List pgsql-bugs
Daniel Farina <daniel@heroku.com> writes:
> From what I can tell, people only see this problem with pg_dump, which
> is interesting. This symptom has a very long history:

Yeah.  There seems to be some well-hidden bug whereby dropping an object
sometimes fails to drop (some of?) its dependencies.  I'm still looking
for a reproducible case, or even a hint as to what the trigger condition
might be.

> In my case, there are two "missing" pg_namespace entries, and both
> have the same missing relations.

Uh, what do you mean by "same missing relations"?

> * There's also a valid version of all these relations/objects that
> *are* connected to the schema that's alive and expected.

And this isn't making any sense to this onlooker, either.  Could you
provide a more detailed explanation of the usage pattern in this
database?  I speculate that what you mean is the user periodically
drops and recreates a schema + its contents, but please be explicit.

> Sadly, for whatever reason, pg_dump --schema=public didn't seem to
> help me out. We do need a workaround if we wish to keep doing
> forensics.

Yeah, pg_dump is written to glom onto everything listed in the catalogs
and sort it out later.  So it tends to notice inconsistencies that you
might not notice in regular usage of the database.  It's sort of hard to
avoid, since for example a --schema switch depends on seeing which
objects belong to which schema ...

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: BUG #5896: When server cannot be started, first it says that it couldn't be started and then Server Started
Next
From: "Scott Dunbar"
Date:
Subject: BUG #5898: Nested "in" clauses hide bad column names