Daniel Farina <dan...@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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
