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

From Tsunakawa, Takayuki
Subject RE: Libpq support to connect to standby server as priority
Date
Msg-id 0A3221C70F24FB45833433255569204D1FB682DB@G01JPEXMBYT05
Whole thread Raw
In response to Re: Libpq support to connect to standby server as priority  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: Libpq support to connect to standby server as priority  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Re: Libpq support to connect to standby server as priority  (Dave Cramer <pg@fastcrypt.com>)
List pgsql-hackers
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(),
andset 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.
 


Regards
Takayuki Tsunakawa




pgsql-hackers by date:

Previous
From: Mithun Cy
Date:
Subject: Re: WIP: Avoid creation of the free space map for small tables
Next
From: Tom Lane
Date:
Subject: Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's