| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Dave Cramer <pg(at)fastcrypt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "laurenz(dot)albe(at)cybertec(dot)at" <laurenz(dot)albe(at)cybertec(dot)at>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Jing Wang <jingwangian(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Libpq support to connect to standby server as priority |
| Date: | 2019-01-15 02:53:17 |
| Message-ID: | 30679.1547520797@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2019-01-15 02:59:05 | Safely calling index_getprocinfo() while holding an nbtree exclusive buffer lock |
| Previous Message | Tsunakawa, Takayuki | 2019-01-15 02:52:38 | RE: Protect syscache from bloating with negative cache entries |