From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Daryl W(dot) Dunbar" <daryl(at)www(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] More postmaster troubles |
Date: | 1999-02-13 20:22:36 |
Message-ID: | 4227.918937356@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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 | Daryl W. Dunbar | 1999-02-13 20:34:30 | RE: [HACKERS] More postmaster troubles |
Previous Message | Tom Lane | 1999-02-13 20:03:17 | Failures in 'rules' regression test |