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 0A3221C70F24FB45833433255569204D1FB68266@G01JPEXMBYT05
Whole thread Raw
In response to Re: Libpq support to connect to standby server as priority  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Michael Paquier <michael@paquier.xyz> writes:
> > On Tue, Jan 15, 2019 at 02:00:57AM +0000, Tsunakawa, Takayuki wrote:
> >> 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.
> 
> > From the point of view of making sure that a client is really
> > connected to  a primary or a standby, this is the best idea around.
> 
> There are a couple of issues here:


> 1. Are you sure there are no use-cases for testing transaction_read_only
> as such?

I don't find any practical use case, but I won't object to leaving the current target_session_attrs as-is.  Alide from
that,I think a parameter like PgJDBC's is necessary, e.g., target_server_type = {primary | standby | prefer_standby},
whichacts based on just the server role (primary or standby).
 



> 2. What will the fallback implementation be, when connecting to a server
> too old to have the variable you want?

One of the following:

1. "Unsupported" error.  I'll take this.
2. libpq issues "SELECT pg_is_in_recovery()".
3. Blindly accepts the first successful connection.


Regards
Takayuki Tsunakawa





pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: current_logfiles not following group access and instead followslog_file_mode permissions
Next
From: Haribabu Kommi
Date:
Subject: Re: What to name the current heap after pluggable storage / what to rename?