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

From Tsunakawa, Takayuki
Subject Re: Patch: Implement failover on libpq connect level.
Date
Msg-id 0A3221C70F24FB45833433255569204D1F63FE73@G01JPEXMBYT05
Whole thread Raw
In response to Re: Patch: Implement failover on libpq connect level.  (Mithun Cy <mithun.cy@enterprisedb.com>)
Responses Re: Patch: Implement failover on libpq connect level.
List 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 by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Floating point comparison inconsistencies of the geometric types
Next
From: Brad DeJong
Date:
Subject: Re: WIP: Covering + unique indexes