Horton
Menu

Thread

  1. Re: [HACKERS] ERROR: infinite recursion in proc_exit

    Tom Lane <tgl@sss.pgh.pa.us> — 1999-11-05T08:01:38Z

    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

  2. Re: [HACKERS] ERROR: infinite recursion in proc_exit

    Jan Wieck <wieck@debis.com> — 1999-11-05T12:48:41Z

    Tom Lane wrote:

> Kristofer Munn <kmunn@munn.com> writes:
> > [PostgreSQL 6.5.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]
>
> 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.

    I  don't  know if you could drop/rebuild an index on a system
    catalog while the database is online.

    But there was sometimes a utility called reindexdb. That used
    the  bootstrap  processing  mode  interface of the backend to
    drop and recreate all system catalog indices.  I  don't  know
    who removed that and why, neither do I know if it would still
    be  possible  to  drop  and  reindex  through  the  bootstrap
    interface.

    Does someone remember why it's gone?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

  3. Re: [HACKERS] ERROR: infinite recursion in proc_exit

    Massimo Dal Zotto <dz@cs.unitn.it> — 1999-11-06T00:45:48Z

    > 
> 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?

The proc_exit_inprogress stuff was added by me after I found some backends
doing exactly that sort of infinite recursion after a socket recv error.
It doesn't correct the original error but at least il will exit the backend
after 10 iterations. The elog(ERROR) might be bogus in this context, but how
can you otherwise notify the error? Maybe a better solution could be this:

	if (proc_exit_inprogress++ == 9)
		elog(ERROR, "infinite recursion in proc_exit");
	if (proc_exit_inprogress >= 9)
		goto exit;

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

  4. Re: [HACKERS] ERROR: infinite recursion in proc_exit

    Bruce Momjian <maillist@candle.pha.pa.us> — 1999-11-06T16:57:38Z

    > > 
> > 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?
> 
> The proc_exit_inprogress stuff was added by me after I found some backends
> doing exactly that sort of infinite recursion after a socket recv error.
> It doesn't correct the original error but at least il will exit the backend
> after 10 iterations. The elog(ERROR) might be bogus in this context, but how
> can you otherwise notify the error? Maybe a better solution could be this:
> 
> 	if (proc_exit_inprogress++ == 9)
> 		elog(ERROR, "infinite recursion in proc_exit");
> 	if (proc_exit_inprogress >= 9)
> 		goto exit;


Fix applied:

    /*
     * If proc_exit is called too many times something bad is happening, so
     * exit immediately.  This is crafted in two if's for a reason.
     */
    if (proc_exit_inprogress == 9)
        elog(ERROR, "infinite recursion in proc_exit");
    if (proc_exit_inprogress >= 9)
        goto exit;


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026