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
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 |