> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> On Mon, Nov 14, 2016 at 8:09 PM, Tsunakawa, Takayuki
> <tsunakawa.ta...@jp.fujitsu.com> wrote:
> > From: pgsql-hackers-ow...@postgresql.org
> >> [mailto:pgsql-hackers-ow...@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 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
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: