> Another thought - what about cluster-aware routing at the protocol level? A > standby could redirect to the primary - similar to 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.
