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 по дате отправления: