Skip site navigation (1) Skip section navigation (2)

Re: Re: 8.3.5: Types with typnamespace pointing at non-existent pg_namespace oid

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Re: 8.3.5: Types with typnamespace pointing at non-existent pg_namespace oid
Date: 2011-02-22 16:54:30
Message-ID: 1652.1298393670@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Daniel Farina <daniel(at)heroku(dot)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

In response to

Responses

pgsql-bugs by date

Next:From: Scott DunbarDate: 2011-02-22 17:26:25
Subject: BUG #5898: Nested "in" clauses hide bad column names
Previous:From: Kevin GrittnerDate: 2011-02-22 16:24:45
Subject: Re: BUG #5896: When server cannot be started, first it says that it couldn't be started and then Server Started

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group