RE: [HACKERS] More postmaster troubles

Tom,

I have to date experienced the problem only with MaxBackendId set to
64.  Today I installed a version of the code with it set to 128
(just picked that number out of luck, but would like to get it
higher).  By the way, I had to tune the kernel to allow me to
increase MaxBackendId, this time in shared memory (SHMMAX).

As for the clients, they are web users via mod_perl/DBI/DBD:Pg.  It
is possible that the user is hitting the stop button right at a time
which hangs the connection (backend), but I have been unable to
reproduce that so far.  That was my first thought on this problem.
The fact that it apparently spirals is disturbing, I highly doubt
there is a user out there hitting the stop key 64 times in a row. :)

Thanks for your help,

DwD

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Saturday, February 13, 1999 3:23 PM
> To: Daryl W. Dunbar
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] More postmaster troubles
>
>
> "Daryl W. Dunbar" <daryl@www.com> writes:
> > Thank you Tatsousan.  This patch will solve the dying process
> > problem when I reach MaxBackendId (which I increased from 64 to
> > 128).  However, I do not know what is causing the
> spiraling death of
> > the processes in the first place. :(
>
> Hmm.  I have noticed at least one place in the code where
> there is an
> undocumented hard-wired dependency on MaxBackendId, to
> wit MAX_PROC_SEMS
> in include/storage/proc.h which is set at 128.
> Presumably it should be
> equal to MaxBackendId (and I intend to fix that soon).
> Evidently that
> particular bug is not hurting you (yet) but perhaps there
> are similar
> errors elsewhere that kick in sooner.  Do you see the
> spiraling-death
> problem if you run with MaxBackendId at its customary value of 64?
>
> The log extract you posted before mentions "fputc()
> failed: errno=32"
> which suggests an unexpected client disconnect during a
> transaction.
> I suspect the backend that gets that disconnect is
> failing to clean up
> properly before exiting, and is leaving one or more locks locked.
> We don't have enough info yet to track down the cause,
> but I suggest
> we could narrow it down some by seeing whether the
> problem goes away
> with a lower MaxBackendId setting.
>
> (You might also want to work on making your clients more robust,
> but I'd like to see if we can solve the backend bug first ...)
>
>             regards, tom lane
>