Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist' - Mailing list pgsql-general

From Tom Lane
Subject Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'
Date
Msg-id 14886.1190650065@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'  (David Brain <dbrain@bandwidth.com>)
Responses Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'  (David Brain <dbrain@bandwidth.com>)
List pgsql-general
David Brain <dbrain@bandwidth.com> writes:
> This is PG version 8.2.3.

> The select returns:

> temptrans,1515546,1515548,16398,0,1515547,0,133873,2.0234e
> +06,1515549,0,f,f,r,24,0,0,0,0,0,f,f,f,f,195484336,,

> What other catalogs would be worth looking in to?  By the way the
> table name here does sort of make sense as to something that may be
> missing, this table is created in a schema that is often dropped/re-
> created.

Hmm, do you rely on "DROP SCHEMA foo CASCADE" to make the contained
objects go away?  We have seen a few reports suggesting that that
sometimes misses some contained objects.  The mechanism for this has
not been identified for sure, but I wonder whether it might have
something to do with the VACUUM-related corruption that we found just
before the latest set of releases.  I'd urge you to update to 8.2.5.

As far as recovery from the immediate problem goes, I'd suggest making a
junk schema, poking its OID into this pg_class row, and then dropping
the table using DROP TABLE (remembering that it will now look like it's
junk.temptrans).  Then you can drop the junk schema and all should be
reasonably OK.

            regards, tom lane

pgsql-general by date:

Previous
From: "Phoenix Kiula"
Date:
Subject: Re: For index bloat: VACUUM ANALYZE vs REINDEX/CLUSTER
Next
From: "Morris Goldstein"
Date:
Subject: pg_dumping large objects