Re: Extensibility of the PostgreSQL wire protocol

On 2/22/21 7:34 AM, Dave Cramer wrote:

> Yes, when did it become a good idea to put a connection pooler in the 
> backend???
> 
> Dave Cramer
> www.postgres.rocks

As Alvaro said, different pool purposes lead to different pool 
architecture and placement.

However, the changes proposed here, aiming at the ability to load 
modified or entirely different wire protocol handlers, do not limit such 
connection pooling. To the contrary.

Any connection pool, that wants to maintain more client connections than 
actual database backends, must know when it is appropriate to do so. 
Usually the right moment to break the current client-backend association 
is when the backend is outside a transaction block and waiting for the 
next client request. To do so pools cannot blindly shovel data back and 
forth. They need to scan one way or another for the backend's 'Z' 
message, sent in tcop/dest.c ReadyForQuery(), where the backend also 
reports the current transaction state. IOW the pool must follow the flow 
of libpq messages on all connections, message by message, row by row, 
just for the purpose of seeing that one, single bit. It is possible to 
transmit that information to the pool on a separate channel.


Regards, Jan

-- 
Jan Wieck
Principle Database Engineer
Amazon Web Services