> Another thought - what about cluster-aware routing at the protocol level? A standby could redirect to the primary -
similarto HTTP 302. The cluster knows its own topology, libpq stays fast and dumb about it.
The cluster knows its topology, from it's own viewpoint. Standby
saying "primary is at 10.0.0.42:5432" isn't helpful to the client,
proxies exist. This is a nice solution in a configuration where
everything uses public IPs and no proxies, as it solves the connection
issue in at most 2 connections, but it doesn't seem to be a 100%
generic always working solution.
> If someone later wanted to replace
> getaddrinfo/connect with a Happy Eyeballs library, to cut down on
> connection times, this proposal would prevent them from doing that.
> (Both your patch, and the other thread's.) Personally I think we
> should reserve the ability to use any API that says "connect me to
> this hostname as fast as possible; I do not care how."
Aren't these just variations to the same question? Which IPs to try to
connect, in which order/parallelism?
In a happy eyeballs analogy, one approach might want to connect to all
listed IPs at the same time, and return the first that responds and is
read write.
