Re: pg_dump and pg_dumpall fail when trying to backup database

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump and pg_dumpall fail when trying to backup database
Дата
Msg-id 8193.1077324691@sss.pgh.pa.us
обсуждение исходный текст
Ответ на pg_dump and pg_dumpall fail when trying to backup database  (jack_turer@yahoo.com (jack turer))
Список pgsql-general
jack_turer@yahoo.com (jack turer) writes:
> I have a database in pgsql (7.3.2) on redhat 9.
> When I try a 'pg_dump mydb' to back up the database, I get:

> -bash-2.05b$ pg_dump -v mydb | more
> pg_dump: saving database definition
> pg_dump: reading namespaces
> pg_dump: reading user-defined types
> pg_dump: could not find namespace with OID 2200
> pg_dump: *** aborted because of error

Hmm, I take it you dropped the public schema at some point?

I think you got bit by this 7.3 bug:

2003-01-08 16:40  tgl

    * src/: backend/catalog/pg_type.c, include/catalog/pg_type.h
    (REL7_3_STABLE): Repair bug noticed by Deepak Bhole: a shell type
    should have a dependency on its namespace, so that it will go away
    if the schema is dropped.

This fix is present in 7.3.2, but if you'd created the shell type while
running 7.3 or 7.3.1 then the dependency would still be lacking after an
update.

Anyway, what you've got is a row in pg_type that refers to a nonexistent
schema.  I'd suggest (as superuser)

SELECT * FROM pg_type WHERE typnamespace = 2200;

to double-check that these rows are not something you want, then

DELETE FROM pg_type WHERE typnamespace = 2200;

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: finding out actual tuple size
Следующее
От: "Ian Harding"
Дата:
Сообщение: Re: I want to use postresql for this app, but...