From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>,
        Dave Cramer <pg@fastcrypt.com>, Robert Haas <robertmhaas@gmail.com>,
        "laurenz.albe@cybertec.at" <laurenz.albe@cybertec.at>,
        Haribabu Kommi <kommi.haribabu@gmail.com>,
        Jing Wang <jingwangian@gmail.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Libpq support to connect to standby server as priority
In-reply-to: <20190115024855.GC1433@paquier.xyz>
References: 
 <CAJrrPGcMq9YgG-aMzLK051EndUgjdnpp8_dJwJaNDZbu=sS0qQ@mail.gmail.com>
 <CAJrrPGcwt0LLLzDF9c3-zWrESJCJko-HovDOrMobkaWQaJ5YUw@mail.gmail.com>
 <67be09458f276c0c95a4b2a2a383dca9775d19cd.camel@cybertec.at>
 <26890.1542047012@sss.pgh.pa.us>
 <096a642cff0dd68b8157a5f8838e1762d0050d18.camel@cybertec.at>
 <28777.1542386147@sss.pgh.pa.us>
 <CA+TgmoY7hRUJyAsDAwgrJVxNVjPgBD50jBccd5795=KQdNz8fw@mail.gmail.com>
 <CADK3HH+eMdju_peR3ugnu6EYQkZB0vzvqrDQVKxDB2+ea3iQfA@mail.gmail.com>
 <26251.1547504236@sss.pgh.pa.us>
 <0A3221C70F24FB45833433255569204D1FB67687@G01JPEXMBYT05>
 <20190115024855.GC1433@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Tue, 15 Jan 2019 11:48:55 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30678.1547520797.1@sss.pgh.pa.us>
Date: Mon, 14 Jan 2019 21:53:17 -0500
Message-ID: <30679.1547520797@sss.pgh.pa.us>
Precedence: bulk

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?

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

			regards, tom lane