Unix socket problem

[Zvirovyi]

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):

        exposed = bool(
            self.database_provides.fetch_relation_field(relation.id, "external-node-connectivity")
        )
        if exposed:
            rw_endpoint = f"{self.charm.leader_ip}:{self.charm.config['listen_port']}"
        else:
            rw_endpoint = f"localhost:{self.charm.config['listen_port']}"

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.

[github-actions]

https://warthogs.atlassian.net/browse/DPE-3988

[dragomirp]

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.

[Zvirovyi]

@dragomirp Do you mean that work on this is in progress / planned?

[dragomirp]

@dragomirp Do you mean that work on this is in progress / planned?

Yes, I will update this ticket when it becomes available.

[taurus-forever]

Just for the history: the Jira issue https://warthogs.atlassian.net/browse/DPE-3988
is a duplicate of https://warthogs.atlassian.net/browse/DPE-4683 and work-in-progress PR is here:
#343
We will resolve this GH issue when PR#343 is merged.