From: pgsql-hackers-ow...@postgresql.org > [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 server_encoding. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers