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

From David Brain
Subject Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'
Date
Msg-id 3CB8E32D-E42B-4B93-9F65-5A117E17A0D8@bandwidth.com
Whole thread Raw
In response to Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Hi,

First, thank you,  things now do seem to be working correctly.

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

Yes - what you describe is exactly what we were doing - fortunately
this isn't something we are relying on day to day, but on the day in
question that is what I was doing.  It looks like an upgrade is in my
future then.

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

Did that - things now seem to working, I'll have to wait till later
to confirm that the complete backup is working, but a schema dump is
working just fine (which it wasn't previously).

Again, thanks for the help, it is this kind of access to assistance
that makes PG a much easier 'sell'.

David.


David Brain
dbrain@bandwidth.com
919.297.1078




pgsql-general by date:

Previous
From: "Morris Goldstein"
Date:
Subject: pg_dumping large objects
Next
From: Erik Jones
Date:
Subject: Re: pg_dumping large objects