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-17T02:57:27Z
Lists: pgsql-hackers
On Wed, Nov 16, 2016 at 9:00 PM, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: > 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. Well, generally speaking, a new feature that works against older server is better than one that doesn't. Of course, if that entails making other compromises then you have to decide whether it's worth it, but SELECT pg_is_in_recovery() and SHOW transaction_read_only exist in older versions so if we pick either of those methods then it will just work. If we decide to invent some completely new method of distinguishing masters from standbys, then it might not, but that would be a drawback of such a choice, not a benefit. -- 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