On Thu, 18 Nov 2004 10:56:59 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Mike Richards <mrmikerich@gmail.com> writes:
> > PANIC: XX000: stuck spinlock (0x4035a0a0) detected at lwlock.c:242
> > ...
> > LOG: 00000: server process (PID 20195) was terminated by signal 11
> > ...
> > FATAL: semctl(0, 0, SETVAL, 0) failed: Identifier removed
>
> If you were getting just one of these then I might think you'd come
> across a previously unknown PG bug. Given the variety of failure modes,
> though, I'm strongly inclined to suspect that the common root cause is
> flaky RAM. Time to get out memtest86 or some such tool.
Here's one more data point. This happens consistently when I try to
run pg_dumpall (always at the same location):
ERROR: XX000: cache lookup failed for attribute 8 of relation 16390
LOCATION: get_rte_attribute_type, parse_relation.c:1573
STATEMENT: SELECT i.indexrelid as indexreloid, coalesce(c.conname,
t.relname) as indexrelname, pg_catalog.pg_get_indexdef(i.indexrelid)
as indexdef, i.indkey, i.indisclustered, t.relnatts as indnkeys,
coalesce(c.contype, '0') as contype, coalesce(c.oid, '0') as conoid
FROM pg_catalog.pg_index i JOIN pg_catalog.pg_class t ON (t.oid =
i.indexrelid) LEFT JOIN pg_catalog.pg_depend d ON (d.classid =
t.tableoid AND d.objid = t.oid AND d.deptype = 'i') LEFT JOIN
pg_catalog.pg_constraint c ON (d.refclassid = c.tableoid AND
d.refobjid = c.oid) WHERE i.indrelid = '95585'::pg_catalog.oid ORDER
BY indexrelname
LOG: 08P01: unexpected EOF on client connection
LOCATION: SocketBackend, postgres.c:281
