Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
Date
Msg-id 5250.917727495@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> BTW, as I pointed out before, PostgreSQL will have serious problem
> once hitting the MaxBackendId. My patches I proposed for this seem
> still under discussion.

Not sure why that didn't get applied before, but I just put it in,
and verified that you can start exactly MaxBackendId backends
(assuming that you don't hit any kernel resource limits on the way).

BTW, we do recover quite gracefully from hitting MAXUPRC (kernel
limit on processes for one userid) :-).  But that's just because the
postmaster's initial fork() fails.  A failure any later than that
in backend startup will be treated as a backend crash ...

I agree with Hannu Krosing's remark that we really need some
documentation about kernel parameters that have to be checked when
setting up a non-toy database server.  I've personally run into
NFILES limits, for instance, with not all that many backends running.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Patrick Welche"
Date:
Subject: Re: [HACKERS] new heap manager mmalloc
Next
From: The Hermit Hacker
Date:
Subject: Re: [DOCS] Re: postgres v6.0 and pgsql-docs-digest V1 #401