Re: Patch: Implement failover on libpq connect level.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: Mithun Cy <mithun.cy@enterprisedb.com>, Peter van Hardenberg <pvh@pvh.ca>, Peter Eisentraut <peter_e@gmx.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-11-15T14:36:46Z
Lists: pgsql-hackers
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
libpq: Add target_session_attrs parameter.
- 721f7bd3cbcc 10.0 landed
-
Remove superuser checks in pgstattuple
- fd321a1dfd64 10.0 cited
-
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
- c405918858c0 9.6.0 cited