From: | "Daryl W(dot) Dunbar" <daryl(at)www(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] More postmaster troubles |
Date: | 1999-02-13 20:34:30 |
Message-ID: | 000801be5790$420c1db0$1445e59b@ddunbar.eni.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Saturday, February 13, 1999 3:23 PM
> To: Daryl W. Dunbar
> Cc: pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: [HACKERS] More postmaster troubles
>
>
> "Daryl W. Dunbar" <daryl(at)www(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-02-13 22:51:04 | Source code cleanup |
Previous Message | Tom Lane | 1999-02-13 20:22:36 | Re: [HACKERS] More postmaster troubles |