Обсуждение: pg_dump: schema with OID 16396 does not exist

Поиск
Список
Период
Сортировка

pg_dump: schema with OID 16396 does not exist

От
RW
Дата:
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

Re: pg_dump: schema with OID 16396 does not exist

От
Tom Lane
Дата:
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

Re: pg_dump: schema with OID 16396 does not exist

От
RW
Дата:
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


Re: pg_dump: schema with OID 16396 does not exist

От
Tom Lane
Дата:
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

Re: pg_dump: schema with OID 16396 does not exist

От
RW
Дата:
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
>
>