From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Mithun Cy' <mithun(dot)cy(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter van Hardenberg <pvh(at)pvh(dot)ca>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch: Implement failover on libpq connect level. |
Date: | 2016-11-14 08:07:31 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F63FE73@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Mithun Cy
> 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.
No, there's no concern about compatibility. Please look at this:
https://www.postgresql.org/docs/devel/static/protocol-flow.html#PROTOCOL-ASYNC
[Excerpt]
----------------------------------------
ParameterStatus messages will be generated whenever the active value changes for any of the parameters the backend believes the frontend should know about. Most commonly this occurs in response to a SET SQL command executed by the frontend, and this case is effectively synchronous — but it is also possible for parameter status changes to occur because the administrator changed a configuration file and then sent the SIGHUP signal to the server. Also, if a SET command is rolled back, an appropriate ParameterStatus message will be generated to report the current effective value.
At present there is a hard-wired set of parameters for which ParameterStatus will be generated: they are server_version, server_encoding, client_encoding, application_name, is_superuser, session_authorization, DateStyle, IntervalStyle, TimeZone, integer_datetimes, and standard_conforming_strings. (server_encoding, TimeZone, and integer_datetimes were not reported by releases before 8.0; standard_conforming_strings was not reported by releases before 8.1; IntervalStyle was not reported by releases before 8.4; application_name was not reported by releases before 9.0.) Note that server_version, server_encoding and integer_datetimes are pseudo-parameters that cannot change after startup. This set might change in the future, or even become configurable. Accordingly, a frontend should simply ignore ParameterStatus for parameters that it does not understand or care about.
----------------------------------------
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Brad DeJong | 2016-11-14 08:17:51 | Re: WIP: Covering + unique indexes |
Previous Message | Kyotaro HORIGUCHI | 2016-11-14 08:05:43 | Re: Floating point comparison inconsistencies of the geometric types |
From | Date | Subject | |
---|---|---|---|
Next Message | Mithun Cy | 2016-11-14 11:05:51 | Re: Patch: Implement failover on libpq connect level. |
Previous Message | Mithun Cy | 2016-11-14 07:56:08 | Re: Patch: Implement failover on libpq connect level. |