Re: Patch: Implement failover on libpq connect level.
Mithun Cy <mithun.cy@enterprisedb.com>
From: Mithun Cy <mithun.cy@enterprisedb.com>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter van Hardenberg <pvh@pvh.ca>, Peter Eisentraut <peter_e@gmx.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-11-14T07:56:08Z
Lists: pgsql-hackers
On Mon, Nov 14, 2016 at 11:31 AM, Tsunakawa, Takayuki < tsunakawa.takay@jp.fujitsu.com> wrote: > PGconn->target_server_type is not freed in freePGconn(). Thanks, will fix in new patch. >Could you add PGTARGETSERVERTYPE environment variable? Like other variables, it will ease testing, since users can change the behavior >without altering the connection string here and there. Okay, will add one. > I think it would be better to expose the server state via ParameterStatus protocol message like standard_conforming_strings, instead of running > >"SELECT pg_is_in_recovery()". We shouldn't want to add one round trip to check the server type (master, standby). postmaster can return the server >type based on its state (pmState); PM_RUN is master, and PM_HOT_STANDBY is standby. In addition, as an impractical concern, DBA can revoke >EXECUTE privilege on pg_is_in_recovery() from non-superusers. If you are suggesting me to change in protocol messages, I think that would not be backward compatible to older version servers. I also think such level of protocol changes will not be allowed. with connection status CONNECTION_SETENV used for protocol version 2.0 setup, we sent some query like "select pg_catalog.pg_client_encoding()" for same. So I think using "SELECT pg_is_in_recovery()" should be fine. - Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com
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