> [] On Behalf Of Robert Haas
> On Mon, Nov 14, 2016 at 8:09 PM, Tsunakawa, Takayuki
> <> wrote:
> > From:
> >> [] On Behalf Of Mithun Cy
> >> Thanks, my concern is suppose you have 3 server in cluster A(new
> >> version), B(new version), C(old version). If we implement as above
> >> only new servers will send ParameterStatus message to indicate what
> >> type of server we are connected. Server C will not send same. So we
> >> will not be able to use new feature "failover to new master" for such
> a kind of cluster.
> >
> > No, the streaming replication requires the same major release for all
> member servers, so there's no concern about the mixed-version cluster.
> True, but there is a concern about a newer libpq connecting to older servers.
> If we mimic what JDBC is already doing, we'll be compatible and you'll be
> able to use this feature with a v10 libpq without worrying about whether
> the target server is also v10.  If we invent something new on the server
> side, then you'll need to be sure you have both a v10 libpq and v10 server.

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 

Takayuki Tsunakawa

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to