Re: Extensibility of the PostgreSQL wire protocol
Alvaro Hernandez <aht@ongres.com>
From: Álvaro Hernández <aht@ongres.com>
To: Jan Wieck <jan@wi3ck.info>, Damir Simunic <damir.simunic@gmail.com>,
Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
"Jonah H. Harris" <jonah.harris@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-02-19T20:39:36Z
Lists: pgsql-hackers
On 19/2/21 19:30, Jan Wieck wrote: > [...] > > I also am not sure if building a connection pool into a background > worker or postmaster is a good idea to begin with. One of the > important features of a pool is to be able to suspend traffic and make > the server completely idle to for example be able to restart the > postmaster without forcibly disconnecting all clients. A pool built > into a background worker cannot do that. > > In my opinion, there are different reasons to use a connection pool, that lead to different placements of that connection pool on the architecture of the system. The ability of a pool to suspend (pause) traffic and apply live re-configurations is a very important one to implement high availability practices, transparent scaling, and others. But these poolers belong to middleware layers (as in different processes in different servers), where these pausing operations make complete sense. Connection poolers fronting the database have other specific missions, namely to control the fan-in of connections to the database. These connection poolers make sense being as close to the database as possible (ideally: embedded) but don't need to perform pause operations here. Álvaro -- Alvaro Hernandez ----------- OnGres