On Thu, 18 Nov 2004 10:56:59 -0500, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Mike Richards <mrmikerich@xxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
