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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'
Дата
Msg-id 14886.1190650065@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'  (David Brain <dbrain@bandwidth.com>)
Ответы Re: pg_dump problem: 'pg_dump: schema with OID 1515546 does not exist'  (David Brain <dbrain@bandwidth.com>)
Список pgsql-general
David Brain <dbrain@bandwidth.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

В списке pgsql-general по дате отправления:

Предыдущее
От: "Phoenix Kiula"
Дата:
Сообщение: Re: For index bloat: VACUUM ANALYZE vs REINDEX/CLUSTER
Следующее
От: "Morris Goldstein"
Дата:
Сообщение: pg_dumping large objects