Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: Patrick Verdon <patrick(at)kan(dot)co(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
Date: 1999-01-30 20:18:15
Message-ID: 5250.917727495@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 1999-01-30 20:34:29 Re: [DOCS] Re: postgres v6.0 and pgsql-docs-digest V1 #401
Previous Message Patrick Welche 1999-01-30 15:08:33 Re: [HACKERS] new heap manager mmalloc