Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Brain <dbrain(at)bandwidth(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'
Date: 2007-09-24 16:07:45
Message-ID: 14886.1190650065@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

David Brain <dbrain(at)bandwidth(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Brain 2007-09-24 17:48:38 Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'
Previous Message Phoenix Kiula 2007-09-24 16:00:53 Re: For index bloat: VACUUM ANALYZE vs REINDEX/CLUSTER