Michael Guerin wrote:
> Hi All,
>
> I've been getting these errors ("ERROR: cache lookup failed for
> relation 17442") in my logs for a while now. It originally seemed
> like a hardware problem, however now we getting them pretty consistently
> on a couple servers. I've scalled down the schema to the one table and
> the function involved and included a code snipet to make a bunch of
> connections and loop around calling the same function. It usually
> takes 100-2000 iterations before these messages start appearing in the
> log. I've also included the original function, this takes 10,000
> iterations for the error to start showing. I should note, we've been
> getting these erros since version 7, this is the first time they were
> reproducable..
>
> With the original function, the log messages were slightly different and
> usually caused the server to reset:
> i.e.
> ERROR: type "t" already exists
> ERROR: duplicate key violates unique constraint
> "pg_type_typname_nsp_index"
> 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
> varchar(50), level int4 )"
> PL/pgSQL function "fngetcompositeids2" line 14 at SQL statement
> ERROR: duplicate key violates unique constraint
> "pg_type_typname_nsp_index"
> ERROR: cache lookup failed for type 2449707570
> FATAL: cache lookup failed for type 2449707570
>
> Environment info: Postgres v8, suse linix with latest kernal patches,
> filesystem: reiserfs.
>
> Please let me know if you need anymore information. No data is need,
> just the schema included.
>
> Thanks
> Michael
>
Michael,
The interesting thing about this bug is: We had the same thing on a
customer's machine some time ago. It actually occurred after a certain
script (nothing big) was run the 100.001st time (maybe) on an empty
database. So this one does not seem to be related to the schema - it is
more or less random ...
The interesting thing is: We copied the data directory from the customer
and we were not able to reproduce the same behaviour on a different machine.
The strange thing is: After doing a checkpoint and restarting the
database the problem still occurred. Starting the same binary thing on a
different machine did not show that error ...
We stepped through it with gdb but we could not find anything strange ...
Can you reliably reproduce the problem after a arbitrary amount of
iterations on a different machine? We couldn't ...
Looking at the code: This is a null pointer caught by the system ...
Something seems to corrupt memory ...
Hans
--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/660/816 40 77
www.cybertec.at, www.postgresql.at
