[pgpool-general: 4023] Re: potential work-around to safely issue pg_terminate_backend()

[Tatsuo Ishii]

>> Yes, SIGTERM, SIGINT a(n)d SIGQUIT cause pgpool child to
>> exit. Unfortunately this has a side effect. Pgpool parent will not
>> fork a new child if child process exits in this case because the
>> child exits with status 0. Pgpool parent only forks new child when
>> the child exits with status other than 0.
> 
> Hi Tatsuo,
> 
> Just so I'm clear, does the above mean the connection pool will have
> one less connection available after one of the processes is kill'd?

Yes.

> If so, is there a way to tell PGPool to re-grow its connection pool
> back to the original number?  For example, sending PGPool a reload?

Currently there's no way to do that. Reloading does not help here. You
need to restart pgpool-II.

BTW, there was an idea when pgpool-II was born. Flexible control over
the number of child process like apache. The idea was, pgpool-II stars
with num_init_children (that's why "init" is in the name), and if lots
of connection requests is coming, more pgpool-II child will be
forked. If the traffic is decreased, some of child process will be
terminated. The idea was to solve the classical problem called
"Thundering Herd" problem, occasionally discussed in this forum (for
example [pgpool-general: 3934]). If we could implement the idea, the
problem (number of child process is not recovered) would be
automatically solved.

Going back to the original problem. Probably pgpool-II parent could
occasionally check the number of child process (maybe in the health
check loop?) and if it is less than num_init_children, it would fork a
new one.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp