Skip site navigation (1) Skip section navigation (2)

Re: fork/exec patch: pre-CreateProcess finalization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
Cc: "'Bruce Momjian '" <pgman(at)candle(dot)pha(dot)pa(dot)us>,"''''Jan Wieck ' ' ' '" <JanWieck(at)Yahoo(dot)com>,"'''''''pgsql-patches(at)postgresql(dot)org' ' ' ' ' ' '" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Date: 2004-01-09 06:15:31
Message-ID: 21143.1073628931@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
> Tom Lane wrote:
>> I think the simplest way to make this work is to use an array that's 
>> 2*MaxBackend items long (corresponding to the max number of children the
>> postmaster will fork).  

> Actually, now that I think about it, is even that big enough. There is a
> reason BackendList is a list. In pathological situations, the postmaster
> could be made to fork a much larger number than 2*MaxBackend simultaneous
> children, although only this many will be allowed to become backends.
> (I guess we could check the port->canAcceptConnections value, and not add
> the backend to the array when == CAC_TOOMANY).

Probably we could rearrange the logic to test for too-many-children
before we even do the fork.  It'd be a little uglier that way, but
not out of the question.

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Tom LaneDate: 2004-01-09 06:21:36
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Previous:From: Tom LaneDate: 2004-01-09 06:14:01
Subject: Re: fork/exec patch: pre-CreateProcess finalization

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group