questions about connection pooling

[fluca1978]

I've two questions when using pgagroal for pooling.
I've a machine that runs pgagroal, and another machine that runs the target PostgreSQL. When I connect from a client thru pgagraol, I see in pg_stat_activity that incoming connection address is the same of the client, while I was expecting it was the pgagroal machine address, since the connection is routed thru the pooler. Therefore, the only way to know if a connection is coming thru the pool is to inspect the application_name, right? Is there any other way?

Second question: is there a way to make pgagroal hold a connection is PostgreSQL is already at its max_connections limit? I mean, assume PostgreSQL has max_connections = 100, can be pgagroal configured to handle max_connection = 200 keeping incoming new request on hold (backlog or blocking_timeout may be)?

[jesperpedersen]

1. I'll have to investigate that, as the client address should be pgagroal not the client. Any help to debug this would be appreciated - debug5 log and possible https://github.com/jesperpedersen/pgprtdbg/ to help...

2. You can keep clients blocking by using blocking_timeout = 0 until they get a connection. But, are you sure that you don't want to notify clients in this case ?

[fluca1978]

1. I'll have to investigate that, as the client address should be pgagroal not the client. Any help to debug this would be appreciated - debug5 log and possible https://github.com/jesperpedersen/pgprtdbg/ to help...

I'm experiencing some different behaviors in the pretty much same setup with pgagroal 1.4.0 and PostgreSQL 14.
I've a pooler machine at 192.168.222.15 and the PostgreSQL machine is at 192.168.222.13, while the host that runs the two virtual machine above is 192.168.222.1.
Now, if I connect thru the pooler, on one setup I've got:

$ psql -U pgbench -h 192.168.222.13 pgbench
Password for user pgbench: 
psql (12.1, server 14.1)
WARNING: psql major version 12, server major version 14.
         Some psql features might not work.
Type "help" for help.

pgbench=> select datname, usename, application_name, client_addr from pg_stat_activity;
 datname | usename  | application_name |  client_addr  
---------+----------+------------------+---------------
         |          |                  | 
         | postgres |                  | 
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | pgagroal         | 192.168.222.1
 pgbench | pgbench  | psql             | 192.168.222.1

therefore I'm connecting directly to PostgreSQL, as shown from the last line (with application_name psql) and the prefil entries are all with the same incoming address, not the one of the pooler machine.

I reproduced the same setup on another host machine, same configuration, and this time the connection address is, as expected, the same of the pooler machine. libev is the same, 4.24.
Since debug5 produces a very verbose list of stuff, is anything particular I should investigate in the first setup to see what the difference could be?
Then I'll try also pgprtdgb!

And, if that matters, the PostgreSQL machine is FreeBSD 13, the pooler is either CentOS 7 (working as expected) or Fedora 33 (the one showing the problem).

2. You can keep clients blocking by using `blocking_timeout = 0` until they get a connection. But, are you sure that you don't want to notify clients in this case ?

Well, I could be misunderstanding, but if I setup with

max_conncetions = 200
blocking_timeout = 0

and then run a pgbench test with all the clients:

% pgbench -c 199 -P 5 -T 30 -U pgbench -h 192.168.222.15 pgbench
pgbench: error: connection to server at "192.168.222.15" (192.168.222.15), port 5432 failed: FATAL:  connection pool is full

while I was expecting this not happening because apparently there is not an overconnection number, and 103 connections should have been on hold. Isn't this right?