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
