Re: Patch: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Mithun Cy
Subject Re: Patch: Implement failover on libpq connect level.
Date
Msg-id CAD__Ouiz1CinaJ1R3D3bruJVsBUnZYXovgaL8Vg34JZXFpWd2w@mail.gmail.com
Whole thread Raw
In response to Re: Patch: Implement failover on libpq connect level.  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses Re: Patch: Implement failover on libpq connect level.
List 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

pgsql-hackers by date:

Previous
From: Mithun Cy
Date:
Subject: Re: Patch: Implement failover on libpq connect level.
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Floating point comparison inconsistencies of the geometric types