Re: 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(at)rentec(dot)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(at)rentec(dot)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(at)rentec(dot)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