From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
> On Mon, Nov 14, 2016 at 8:09 PM, Tsunakawa, Takayuki
> <tsunakawa.takay@jp.fujitsu.com> wrote:
> > From: pgsql-hackers-owner@postgresql.org
> >> [mailto:pgsql-hackers-owner@postgresql.org] 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
andlibpq failover is a new feature in PostgreSQL 10. At least, as one user, I don't want PostgreSQL to sacrifice
anotherround trip to establish a connection. As a developer, I don't want libpq code more complex than necessary (the
proposedpatch adds a new state to the connection state machine.) And I think it's natural for the server to return the
serverattribute (primary/standby, writable, etc.) as a response to the Startup message like server_version,
standard_conforming_stringsand server_encoding.
Regards
Takayuki Tsunakawa