Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Date
Msg-id CA+TgmoaULj0A9JK_cDg63C7d8zZDdr=SiwnyoGfm1VHWA8SuNg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby"GUC pseudo-variable.  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby"GUC pseudo-variable.  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On Wed, May 24, 2017 at 3:16 AM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> I confirmed that the attached patch successfully provides:
>
> * target_session_attrs=read-only
> * If the server is >= 10, avoid the round-trip for SHOW transaction_read_only.
>
> For this, I added a GUC_REPORT variable session_read_only which indicates the session's default read-only status.
Thecharacteristics are: 
>
> * It cannot be changed directly by the user (postgresql.conf, SET, etc.)
> * Its value is the same as default_transaction_read_only when not in recovery.
> * Its value is false during recovery.
>
> Could you include this in PG 10?  I think these are necessary as the bottom line to meet the average expectation of
users(please don't ask me what's the average; the main reasons are that PostgreSQL provides hot standby, PgJDBC enables
connectionto the standby (targetServerType=slave), and PostgreSQL emphasizes performance.)  Ideally, I wanted to add
otherfeatures of PgJDBC (e.g. targetServerType=preferSlave), but I thought this is the limit not to endanger the
qualityof the final release. 

I've already stated my position on this, which is that:

* target_session_attrs=read-only is a perfectly good new feature, but
we're past feature freeze, so it's material for v11.

* I'm not opposed to adding a GUC_REPORT GUC of some kind, but I see
no urgency about that either.  The feature works fine as it is.  The
fact that it could possibly be made to work more efficiently is not a
critical bug.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] unreachable code in partition.c
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.