Open Zvirovyi opened 2 months ago
As part of the support for multiple databases in Pgbouncer, instances run in most clients will be reduced to 1, so socket should be viable then.
@dragomirp Do you mean that work on this is in progress / planned?
@dragomirp Do you mean that work on this is in progress / planned?
Yes, I will update this ticket when it becomes available.
Hi! Previously, I have been told by Canonical team, that pgbouncer-operator is following mysql-router concept with Unix socket propagation to the client application. But i did research and found that it doesn't work that way: instead, it uses TCP port for both exposed and not exposed relations (it is code snippet, but everything were double-checked in real tests):
link to the relations code
Mysql-router, on the other hand, really propagates single Unix socket. Issue lays in that pgbouncer-operator was made as subordinate charm only with assumption, that it will work with similar concept as mysql-router.
Also, there is no mentions of Unix socket in application and relation specification documentations - i think it should be.
And about pgbouncer and it's multithreading
Pgbouncer creates N processes (for each CPU core / thread), and each process has it's own TCP port and Unix socket. In the TCP case, all the ports are combined by so_reuseport, which also includes load balancing. But for the Unix socket, there is no such feature to combine them all, so basically there is N different Unix sockets, and in case these all sockets will be reported to the client application, there wouldn't be any automatic load balancing (and therefore multithreading) - it will be only on the client application responsibility.