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
