<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks Tatsuo</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Is there any plan for this fix to be included in an upcoming Pgpool release (I am running 4.2.4 from Alpine repositories)  ?</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Or, do you consider this as too deployment-specific (and so I should create a custom build from source of 4.2.4)?<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"> <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 18, 2021 at 11:36 AM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> In our environment:<br>
>> reserved_connections=0<br>
>> listen_backlog_multiplier=2<br>
>> <br>
>> So, if I understand correctly, we have 2 different problematic cases:<br>
>> <br>
>> (1) a client silently disappears (doesn't properly close the connection):<br>
>> In this case, setting `child_idle_limit` to a non-zero value (say 15min)<br>
>> could mitigate the problem, and eventually the child worker will again be<br>
>> available to handle an incoming connection.<br>
>><br>
>> (2) a server-side child process crashes: In this case, Pgpool still keeps a<br>
>> dangling reference to this process, and if some client is routed there will<br>
>> get a "sorry, too many clients" error.<br>
> <br>
> Since the counter is shared by all process, any process could get a<br>
> "sorry..." error.<br>
> <br>
>> As for now, this problem cannot be<br>
>> mitigated unless the (parent) Pgpool process is restarted.<br>
> <br>
> Yes.<br>
> <br>
>> One more question:<br>
>> What can make a child process crash? (well, I mean, what are the most<br>
>> common reasons for that).<br>
> <br>
> Besides admin's mistake, probabbly the most case is OOM killer.<br>
> <br>
>> Does this crash leave any trace (that I should search for) in Pgpool's<br>
>> error log? Does parent Pgpool get notified on this (e.g. via waitpid or<br>
>> SIGCHLD)?<br>
> <br>
> Yes, Pgpool parent process should leave a log when catching SIGCHLD.<br>
> If I kill a child process using kill -9, I got following log:<br>
> <br>
> 2021-10-18 14:44:48.951: main pid 997555: LOG:  child process with pid: 997582 exits with status 9 by signal 9<br>
> 2021-10-18 14:44:48.952: main pid 997555: LOG:  fork a new child process with pid: 997609<br>
<br>
Actually if reserved_connections=0, then there's no need to manage the<br>
connection counter. So I have created a patch to eliminate the<br>
management part. You will never be troubled by the "sorry..."  error.<br>
<br>
If you like, please try attached patch.<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
</blockquote></div>