Re: [HACKERS] ERROR: infinite recursion in proc_exit

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kristofer Munn <kmunn(at)munn(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] ERROR: infinite recursion in proc_exit
Date: 1999-11-05 08:01:38
Message-ID: 29498.941788898@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kristofer Munn <kmunn(at)munn(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Simms 1999-11-05 10:35:47 Re: [HACKERS] New version of psql
Previous Message Kristofer Munn 1999-11-05 06:37:35 Re: [HACKERS] ERROR: infinite recursion in proc_exit