Обсуждение: 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 > >