Обсуждение: pg_dump: schema with OID 16396 does not exist
Hi everybody, I have a problem with pg_dump. After dropping a database (DROP DATABASE ...) I've created the database again (CREATE DATABASE ...) and restored a dump which we create every night. No problem so far and import was no problem and without errors. But now it isn't possible to make a backup because of the following error: pg_dump: schema with OID 16396 does not exist Postgres version is 8.1.4 and OS is Redhet ES 4 U3. I've already had the same problem on a completely different database (Version 8.1.3) on a different host same szenario. But in this case I've had the possibility to drop the entire cluster, started a initdb and do the restore. Problem solved. This is not possible with this cluster so I need a real solution for the problem. When I look at pg_namespace mps_dev=# select * from pg_namespace ; nspname | nspowner | nspacl --------------------+----------+------------------------------------------------------- pg_toast | 10 | pg_temp_1 | 10 | pg_catalog | 10 | {postgres=UC/postgres,=U/postgres} information_schema | 10 | {postgres=UC/postgres,=U/postgres} as_mps_d_p | 16387 | cms_mps_d_p | 16389 | {cms_mps_d_p=UC/cms_mps_d_p,as_mps_d_p=U/cms_mps_d_p} public | 10 | {postgres=UC/postgres,=UC/postgres} (7 rows) there is no nspacl for schema as_mps_d_p. Seems strange to me. Thanks for any hint. - Robert
RW <postgres@tauceti.net> writes: > pg_dump: schema with OID 16396 does not exist I assume you don't see that OID in "select oid,nspname from pg_namespace"? Look through the system catalogs to find the object(s) that claim to be in that namespace, and then tell us what they are and their history. select * from pg_type where typnamespace = 16396 and likewise for pg_class.relnamespace, pg_operator.oprnamespace, pg_conversion.connamespace, pg_opclass.opcnamespace, pg_aggregate.aggnamespace, pg_proc.pronamespace. regards, tom lane
Hi Tom, thanks for your answer. >> pg_dump: schema with OID 16396 does not exist > > I assume you don't see that OID in "select oid,nspname from pg_namespace"? > Yes, that's right. > Look through the system catalogs to find the object(s) that claim to be > in that namespace, and then tell us what they are and their history. > > select * from pg_type where typnamespace = 16396 > > and likewise for pg_class.relnamespace, pg_operator.oprnamespace, > pg_conversion.connamespace, pg_opclass.opcnamespace, > pg_aggregate.aggnamespace, pg_proc.pronamespace. > Found it in pg_conversion: mps_dev=# select * from pg_conversion where connamespace = 16396; conname | connamespace | conowner | conforencoding | contoencoding | conproc | condefault ---------------------+--------------+----------+----------------+---------------+-------------------+------------ iso_8859_1_to_utf_8 | 16396 | 16389 | 8 | 6 | iso8859_1_to_utf8 | t (1 row) The owner is the user cms_mps_d_p. [postgres@host1202~]$ psql -d mps_dev -U cms_mps_d_p mps_dev=> \dc List of conversions Schema | Name | Source | Destination | Default? -------------+-----------------------------+---------------+---------------+---------- cms_mps_d_p | iso_8859_1_to_utf_8 | LATIN1 | UTF8 | yes ... Well I remember that our developers created such a function but they don't need it anymore. Could I simply drop it to solve the problem with pg_dump? But anyway... How can this be avoided and why does such a sitiation occur? I just dropped the database, created a new one (with the same name) and started a restore (completed with no errors). This procedure seems not so unusual to me ;-) And it happens the second time to me. Thanks, Robert
RW <postgres@tauceti.net> writes: >> Look through the system catalogs to find the object(s) that claim to be >> in that namespace, and then tell us what they are and their history. > Found it in pg_conversion: > mps_dev=# select * from pg_conversion where connamespace = 16396; > conname | connamespace | conowner | conforencoding | > contoencoding | conproc | condefault > ---------------------+--------------+----------+----------------+---------------+-------------------+------------ > iso_8859_1_to_utf_8 | 16396 | 16389 | 8 > | 6 | iso8859_1_to_utf8 | t > (1 row) Ah. This is a known bug: CREATE CONVERSION neglected to enter a dependency from the new conversion to its namespace, hence a DROP SCHEMA on the namespace would not remove the pg_conversion entry. This is fixed in HEAD but hasn't been back-patched for some reason --- I'll go deal with that now. In the meantime I'd suggest a manual DROP CONVERSION to clean up ... hmm ... except you probably can't name that conversion anymore in SQL, what with it not having a schema. I think it would work well enough to just DELETE the specific row in pg_conversion. regards, tom lane
Hi Tom, deleted entry from pg_conversion. Problem solved. pg_dump works again. Thanks, Robert Tom Lane wrote: >>>Look through the system catalogs to find the object(s) that claim to be >>>in that namespace, and then tell us what they are and their history. >>> >>> > > > >>Found it in pg_conversion: >> >> > > > >>mps_dev=# select * from pg_conversion where connamespace = 16396; >> conname | connamespace | conowner | conforencoding | >>contoencoding | conproc | condefault >>---------------------+--------------+----------+----------------+---------------+-------------------+------------ >> iso_8859_1_to_utf_8 | 16396 | 16389 | 8 >>| 6 | iso8859_1_to_utf8 | t >>(1 row) >> >> > > >Ah. This is a known bug: CREATE CONVERSION neglected to enter a dependency >from the new conversion to its namespace, hence a DROP SCHEMA on the >namespace would not remove the pg_conversion entry. This is fixed in >HEAD but hasn't been back-patched for some reason --- I'll go deal with >that now. > >In the meantime I'd suggest a manual DROP CONVERSION to clean up ... >hmm ... except you probably can't name that conversion anymore in SQL, >what with it not having a schema. I think it would work well enough to >just DELETE the specific row in pg_conversion. > > regards, tom lane > >