Kristofer Munn <kmunn@munn.com> writes:
>> What Postgres version are you using?
> My apologies, should have included that with my original request:
> [PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]
Hmm. If that trace is from 6.5 code, then postgres.c should certainly
be calling proc_exit after the recv() fails. I wonder if proc_exit is
returning because proc_exit_inprogress is nonzero? proc_exit's use of
elog(ERROR) does look mighty bogus to me --- that path could possibly
cause a recursion just like this, but how did the code get into it to
begin with?
But that's not very relevant to your real problem, which is that
there must be something corrupted in pg_attribute's indexes.
> What are the ramifications of continuing with the corrupted indexes -
> undefined behavior?
I wouldn't recommend it.
> Filesystems have fsck to fix stuff - are there any
> tools on the docket to reconstruct the indexes or other recoverable
> things?
I've thought for some time that vacuum ought to just rebuild the indexes
from scratch. That'd provide a recovery path for this sort of problem,
and I suspect it'd actually be faster than what vacuum does now. I'm
not volunteering to make it happen, though.
regards, tom lane