On Tue, Sep 1, 2015 at 8:12 PM, Andres Freund <andres@anarazel.de> wrote:
On 2015-09-01 14:07:19 -0400, Robert Haas wrote: > But I think it's quite wrong to assume that the infrastructure for > this is available and usable everywhere, because in my experience, > that's far from the case.
Especially when the alternative is a rather short patch implementing an otherwise widely available feature.
But that won't actually help in the case described by Robert: if the master server A failed, the client has no idea if B or C would become the new master.
Unless it actually tries to connect them in turn and check for the result of pg_is_in_recovery(). I think that brings enough complexity for keeping this outside of libpq. Also think about all the extra flexibility people will likely want to have: number of retries, delay between retries, delay backoff, etc., to the point we'll have to support some sort of client code retry_policy_callback.
For read-only clients you might want to include a number of slave hostnames, and let the connector choose one, but then again you can't achieve load-balancing on the client side, you're better off using round-robin DNS. To add or remove a slave you only need to update DNS, and not configuration on all the clients.
For the master failover I think a common technique is to just move the floating IP address from the old master to the new one. This doesn't require touching the DNS record.
