Re: Patch: Implement failover on libpq connect level.
От | Tsunakawa, Takayuki |
---|---|
Тема | Re: Patch: Implement failover on libpq connect level. |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F63FE73@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: Patch: Implement failover on libpq connect level. (Mithun Cy <mithun.cy@enterprisedb.com>) |
Ответы |
Re: Patch: Implement failover on libpq connect level.
|
Список | pgsql-hackers |
From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.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 believesthe 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 becausethe administrator changed a configuration file and then sent the SIGHUP signal to the server. Also, if a SET commandis 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_datetimeswere not reported by releases before 8.0; standard_conforming_strings was not reported by releases before8.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 ParameterStatusfor parameters that it does not understand or care about. ---------------------------------------- Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: