Обсуждение: ERROR: duplicate key violates unique constraint "pg_type_typname_nsp_index"

Hi,

     I'm not sure what the cause of this error is, but I figured I
should post it.  I had to restore from back to stop getting these errors
"ERROR:  cache lookup failed for type 813612037" .   This was from a
database running beta4, i'm now running beta5.

-michael

LOG:  unexpected EOF on client connection
ERROR:  duplicate key violates unique constraint "pg_type_typname_nsp_index"
ERROR:  duplicate key violates unique constraint "pg_type_typname_nsp_index"
CONTEXT:  SQL statement "create temp table tmp_children ( uniqid bigint,
memberid bigint, membertype varchar(50), ownerid smallint, tag varc
har(50), level int4 )"
        PL/pgSQL function "fngetcompositeids2" line 14 at SQL statement
ERROR:  duplicate key violates unique constraint "pg_type_typname_nsp_index"
CONTEXT:  SQL statement "create temp table tmp_children ( uniqid bigint,
memberid bigint, membertype varchar(50), ownerid smallint, tag varc
har(50), level int4 )"
        PL/pgSQL function "fngetcompositeids2" line 14 at SQL statement
ERROR:  cache lookup failed for type 813612037
FATAL:  cache lookup failed for type 813612037
LOG:  server process (PID 10449) exited with exit code 1
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process exit
ed abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process exit
ed abnormally and possibly corrupted shared memory.
--More--(74%)

Michael Guerin <guerin@rentec.com> writes:
>      I'm not sure what the cause of this error is, but I figured I
> should post it.

> ERROR:  duplicate key violates unique constraint "pg_type_typname_nsp_index"
> ERROR:  duplicate key violates unique constraint "pg_type_typname_nsp_index"
> CONTEXT:  SQL statement "create temp table tmp_children ( uniqid bigint,
> memberid bigint, membertype varchar(50), ownerid smallint, tag varc
> har(50), level int4 )"

Hmm.  It looks like the source of the problem is an
only-partially-deleted temp table left behind by some prior failure.
Specifically, the rowtype entry for the table is still there in
pg_type, though its pg_class entry must be gone or you'd have gotten
a different error message.  This seems pretty odd, since the catalog
entries should have been deleted in a single transaction.

Can you look back just before you started getting these, and see if
there is any record of a backend crashing during exit?

It's too bad you already restored from backup, since you've now wiped
out all the evidence ...

            regards, tom lane

Tom Lane wrote:

>Michael Guerin <guerin@rentec.com> writes:
>
>
>>     I'm not sure what the cause of this error is, but I figured I
>>should post it.
>>
>>
>
>
>
>>ERROR:  duplicate key violates unique constraint "pg_type_typname_nsp_index"
>>ERROR:  duplicate key violates unique constraint "pg_type_typname_nsp_index"
>>CONTEXT:  SQL statement "create temp table tmp_children ( uniqid bigint,
>>memberid bigint, membertype varchar(50), ownerid smallint, tag varc
>>har(50), level int4 )"
>>
>>
>
>Hmm.  It looks like the source of the problem is an
>only-partially-deleted temp table left behind by some prior failure.
>Specifically, the rowtype entry for the table is still there in
>pg_type, though its pg_class entry must be gone or you'd have gotten
>a different error message.  This seems pretty odd, since the catalog
>entries should have been deleted in a single transaction.
>
>Can you look back just before you started getting these, and see if
>there is any record of a backend crashing during exit?
>
>It's too bad you already restored from backup, since you've now wiped
>out all the evidence ...
>
>            regards, tom lane
>
>
It's a production database, so I had to get it back online.  I did
however leave the old files around, and restored to a new db install.
I'll startup the old files on another port to poke around.  I believe
the only restart happened after the error, i'll confirm this.

-michael

Michael Guerin <guerin@rentec.com> writes:
> Tom Lane wrote:
>> It's too bad you already restored from backup, since you've now wiped
>> out all the evidence ...
>>
> It's a production database, so I had to get it back online.

[ raised eyebrow ]  You're running a production server on a beta release?
You're braver than I am.

            regards, tom lane