On Tue, Sep 1, 2015 at 8:12 PM, Andres Freund <and...@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. -- Alex
