From: | Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it> |
---|---|
To: | hackers(at)postgreSQL(dot)org (PostgreSQL Hackers) |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) |
Subject: | Re: [HACKERS] ERROR: infinite recursion in proc_exit |
Date: | 1999-11-06 00:45:48 |
Message-ID: | 199911060045.BAA03089@nikita.dz.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> 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(at)cs(dot)unitn(dot)it |
| Via Marconi, 141 phone: ++39-0461534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: finger dz(at)tango(dot)cs(dot)unitn(dot)it |
+----------------------------------------------------------------------+
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 1999-11-06 01:57:51 | PostgreSQL 6.5.3 STABLE RPMs released. |
Previous Message | Stuart Woolford | 1999-11-06 00:05:14 | Re: [HACKERS] Re: [GENERAL] indexed regex select optimisation missing? |