From: | Jan Wieck <jan(at)wi3ck(dot)info> |
---|---|
To: | Dave Cramer <davecramer(at)postgres(dot)rocks>, Álvaro Hernández <aht(at)ongres(dot)com> |
Cc: | Damir Simunic <damir(dot)simunic(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Extensibility of the PostgreSQL wire protocol |
Date: | 2021-02-22 14:55:53 |
Message-ID: | c6e386a2-ad2e-c950-a14a-2fa80085849e@wi3ck.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2021-02-22 15:01:41 | Re: Extensibility of the PostgreSQL wire protocol |
Previous Message | Andrew Dunstan | 2021-02-22 14:46:50 | Re: Finding cause of test fails on the cfbot site |