On Thu, Nov 17, 2016 at 10:08 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 17 November 2016 at 10:57, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Nov 16, 2016 at 9:00 PM, Tsunakawa, Takayuki >> <tsunakawa.ta...@jp.fujitsu.com> wrote: >>> Do we really want to enable libpq failover against pre-V10 servers? I >>> don't think so, as libpq is a part of PostgreSQL and libpq failover is a >>> new feature in PostgreSQL 10. At least, as one user, I don't want >>> PostgreSQL to sacrifice another round trip to establish a connection. As a >>> developer, I don't want libpq code more complex than necessary (the >>> proposed patch adds a new state to the connection state machine.) And I >>> think it's natural for the server to return the server attribute >>> (primary/standby, writable, etc.) as a response to the Startup message like >>> server_version, standard_conforming_strings and server_encoding. >> >> Well, generally speaking, a new feature that works against older >> server is better than one that doesn't. Of course, if that entails >> making other compromises then you have to decide whether it's worth >> it, but SELECT pg_is_in_recovery() and SHOW transaction_read_only >> exist in older versions so if we pick either of those methods then it >> will just work. If we decide to invent some completely new method of >> distinguishing masters from standbys, then it might not, but that >> would be a drawback of such a choice, not a benefit. > > We can and probably should have both. > > If the server tells us on connect whether it's a standby or not, use that. > > Otherwise, ask it. > > That way we don't pay the round-trip cost and get the log spam when > talking to newer servers that send us something useful in the startup > packet, but we can still query it on older servers. Graceful fallback. > > Every round trip is potentially very expensive. Having libpq do them > unnecessarily is bad.
True, but raising the bar for this feature so that it doesn't get done is also bad. It can be improved in a later patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
