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:

Reply via email to