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

Поиск
Список
Период
Сортировка
От David Brain
Тема Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'
Дата
Msg-id 3CB8E32D-E42B-4B93-9F65-5A117E17A0D8@bandwidth.com
обсуждение исходный текст
Ответ на Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Morris Goldstein"
Дата:
Сообщение: pg_dumping large objects
Следующее
От: Erik Jones
Дата:
Сообщение: Re: pg_dumping large objects