Connection pooling about stolon HOT 7 CLOSED

Sorry if this is a dumb question: Would it make sense to simply put a pgpool/pgbouncer in front of stolon proxy in order to ensure connection pooling (and only pooling in pgpool case)?

from stolon.

@thedrow Actually the proxy is just a a dumb tcp proxy so for every incoming tcp connection it opens a tcp connection to the current master. This was done for different needs:

• Have multiple proxies to avoid any spof.
• Let the data pass between the client and the proxy untouched.

Keeping a connection pool cannot probably be done with a layer 4 proxy like the actual but needs a layer7 proxy making the proxy talk the postgres protocol with the client and with the server

I understand your requirement since some application aren't keeping an own connection pool but I'm not sure this needs to be a function provided by the stolon proxy since its main purpose is to direct clients to the right master.

Since, for an application, connecting to the stolon proxy is the same as directly connecting to the stolon master (what changes is just the ip to connect to), what about using already existing connection polling mechanism (like pgpool-II in connection pooling mode that will point to the stolon proxy)?

from stolon.

That is entirely possible but incurs the overhead of transmitting the query and the results through two proxies.
Extending the proxy's capability to be a smarter implementation of pgpool-II will provide more value to the community.
The question is if we want stolon to be a one stop shop for all our PG operational needs or if we'd like to provide a partial solution that will require us to use other components in order to achieve our operational goals.

from stolon.

Closing since making the proxy a pgpool clone doesn't makes sense and doesn't fit with the stolon architecture. Plus connection pooling should be done by the application.

from stolon.

I'd like to ask the same question as @davidberardozzi .
I intend to access stolon from a serverless architecture, where it's hard or even impossible for the application to do the pooling by itself (in the sense that each HTTP endpoint is backed by just one single stateless lambda/function, not a stateful application), an external pooler is required.

from stolon.

@ccll the stolon-proxy purpose is to redirect to the right master and close connections to old masters, adding connection pooling to it is another feature that will require a lot of work, make the proxy talk at layer 7 and not layer 4 and do all the work that pgpool is already doing (i.e. reset session). The solution is to make your application talks with pgpool and pgpool will point the stolon proxies. The overhead of adding another hop should be negligible.

from stolon.

@sgotti External pooling looks cool, I'll try that later, thanks for the tip.

from stolon.