Re: Libpq support to connect to standby server as priority - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: Libpq support to connect to standby server as priority
Date
Msg-id CADK3HH+phRtMRf5+FzeATvzqsD8hF=gHbz7vhcLM1MC4dv3TRw@mail.gmail.com
Whole thread Raw
In response to RE: Libpq support to connect to standby server as priority  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers


On Tue, 15 Jan 2019 at 23:21, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
From: Dave Cramer [mailto:pg@fastcrypt.com]
>       The original desire should have been the ability to connect to a
> primary or a standby.  So, I think we should go back to the original thinking
> (and not complicate the feature), and create a read only GUC_REPORT variable,
> say, server_role, that identifies whether the server is a primary or a
> standby.
>
>
>
> I'm confused as to how this would work. Who or what determines if the server
> is a primary or standby?

Overall, the server determines the server role (primary or standby) using the same mechanism as pg_is_in_recovery(), and set the server_role GUC parameter.  As the parameter is GUC_REPORT, the change is reported to the clients using the ParameterStatus ('S') message.  The clients also get the value at connection.

Thanks, that clarifies it.


pgsql-hackers by date:

Previous
From: Surafel Temesgen
Date:
Subject: Re: pg_dump multi VALUES INSERT
Next
From: Dave Cramer
Date:
Subject: Re: Libpq support to connect to standby server as priority