RE: Libpq support to connect to standby server as priority

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'Haribabu Kommi' <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Cramer <pg(at)fastcrypt(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-03-27 04:41:05
Message-ID: 0A3221C70F24FB45833433255569204D1FBEA9BC@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

From: Haribabu Kommi [mailto:kommi(dot)haribabu(at)gmail(dot)com]
> while going through the old patch where the GUC_REPORT is implemented, Tom
> has commented the logic of sending the signal to all backends to process
> the hot standby exit with SIGHUP, if we add the logic of updating the GUC
> variable value in SIGHUP, we may need to change all the SIGHUP handler code
> paths. It is also possible that there is no need to update the variable
> for other processes except backends.
> If we go with adding the new SIGUSR1 type to check and update the GUC varaible
> can work for most of the backends and background workers.
> opinions

SIGUSR1 looks reasonable. We can consider it as notifying that the server status has changed.

I've fully reviewed 0001-0003 and my comments follow. I'll review 0004-0007.

(1) 0001
before issuing the transaction_readonly to find out whether
the server is read-write or not is restuctured under a new

transaction_readonly -> "SHOW transaction_read_only"
restuctured -> restructured

(2) 0001
+ succesful connection or failure.
+ successful connection; if it returns <literal>on</literal>, means server

succesful -> successful
means -> it means

(3) 0003
+ But for servers version 12 or greater uses the <varname>transaction_read_only</varname>
+ GUC that is reported by the server upon successful connection.

GUC doesn't seem to be a term to be used in the user manual. Instead:

uses the value of <varname>transaction_read_only</varname> configuration parameter that is...

as in:

This sets the client_encoding configuration parameter for this connection.

Specifies a value for the application_name configuration parameter.

(4) 0003
bool std_strings; /* standard_conforming_strings */
+ bool transaction_read_only; /* session_read_only */

Looking at the comment for std_strings, it's better to change the comment to transaction_read_only to represent the backing configuration parameter name.

Takayuki Tsunakawa

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-03-27 04:50:59 Re: speeding up planning with partitions
Previous Message Masahiko Sawada 2019-03-27 04:13:19 Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits