Re: fork/exec patch: pre-CreateProcess finalization
От | Claudio Natoli |
---|---|
Тема | Re: fork/exec patch: pre-CreateProcess finalization |
Дата | |
Msg-id | A02DEC4D1073D611BAE8525405FCCE2B55F23F@harris.memetrics.local обсуждение исходный текст |
Ответ на | fork/exec patch: pre-CreateProcess finalization (Claudio Natoli <claudio.natoli@memetrics.com>) |
Ответы |
Re: fork/exec patch: pre-CreateProcess finalization
|
Список | pgsql-patches |
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). > There is no race condition possible for the ProcessCancelRequest case --- > the sub-postmaster that spawned an active backend must have found its > entry before it could have sent the cancel key to the client, so any > valid cancel request from a client must reference an already-existing > entry in the array. Make sense. Great. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
В списке pgsql-patches по дате отправления: