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.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: