Re: pg_dump and pg_dumpall fail when trying to backup database

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jack_turer(at)yahoo(dot)com (jack turer)
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump and pg_dumpall fail when trying to backup database
Date: 2004-02-21 00:51:31
Message-ID: 8193.1077324691@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

jack_turer(at)yahoo(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Christopher Browne 2004-02-21 02:15:43 Re: embeding postgre
Previous Message Tom Lane 2004-02-21 00:43:30 Re: finding out actual tuple size