Re: Patch: Implement failover on libpq connect level.

On Thu, Nov 17, 2016 at 10:08 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 17 November 2016 at 10:57, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Nov 16, 2016 at 9:00 PM, Tsunakawa, Takayuki
>> <tsunakawa.takay@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