[pgpool-hackers: 3155] Re: Proposal: limiting number of frontends differently

[Tatsuo Ishii]

> This is a proposal for Pgpool-II 4.1.
> 
> Currently Pgpool-II accepts up to num_init_children frontends and
> queues up more connection requests until one of child process becomes
> free. This mostly works well, but if each session take long time, the
> queue grows long and the whole system does not work smoothly.
> 
> To overcome the problem, I propose a new way to deal with many
> connection requests from frontend: just complain and refuses to
> connect to Pgpool-II if number of num_init_children is already filled
> up. This is exactly the same behavior as PostgreSQL.
> 
> Attached PoC patch demonstrates how the new behavior works. If
> connection request comes more than num_init_children - 1 comes in, the
> frontend gets an error:
> 
> 	 FATAL:  Sorry, too many clients already
> 
> and it cannot connect to Pgpool-II.
> 
> I think existing behavior of Pgpool-II is suitable for some users but
> others might want the new way, and we should provide a switch to allow
> users to choose their favorite behaviors.
> 
> Maybe something like "queue_incoming_connection"? If true, then
> existing behavior is chosen (queue incoming connections).

After thinking more, I believe the type of queue_incoming_connection
is better to be integer, rather than boolean. I mean
queue_incoming_connection is:

0: keep the existing behavior. i.e. queuing up incoming connections requests.

positive integer n: complain if new connection request is coming while
number of connection reaches num_init_children - n.

For example, if num_init_children = 32 and queue_incoming_connection =
1, then Pgpool-II accepts up to 31 connections. But the 32th
connection request will be refused and get "FATAL: Sorry, too many
clients already" message. The advantage of this is, user can control
precisely the acceptable max connections. Since on a high load system,
the connection count may temporary exceed num_init_children - 1 (a
connection is finished but the post process may not finish yet). In
this case users may want to set n to higher value, like 5 or even 10.

So maybe I should change the variable name to something like
"connection_reserve"?

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