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

From Tsunakawa, Takayuki
Subject Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby"GUC pseudo-variable.
Date
Msg-id 0A3221C70F24FB45833433255569204D1F6F2FC9@G01JPEXMBYT05
Whole thread Raw
In response to Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Craig Ringer
> On 13 April 2017 at 14:59, Tsunakawa, Takayuki
> <tsunakawa.takay@jp.fujitsu.com> wrote:
> 
> > 2. Make transaction_read_only GUC_REPORT This is to avoid the added
> > round-trip by SHOW command.  It also benefits client apps that want to
> know when the server gets promoted?  And this may simplify the libpq code.
> > I don't understand yet why we need to provide this feature for older servers
> by using SHOW.  Those who are already using <= 9.6 in production completed
> the system or application, and their business is running.  Why would they
> want to just replace libpq and use this feature?
> 
> I think "transaction_read_only" is a bit confusing for something we're
> expecting to change under us.
> 
> To me, a "read only" xact is one created with
> 
> BEGIN READ ONLY TRANSACTION;
> 
> .... which I would not expect to become read/write under me, since I
> explicitly asked for read-only.
> 
> It's more like "session read only" that we're interested in IMO.

Are you suggest thating we provide a GUC_REPORT read-only variable "session_read_only" and the libpq should use it?

Anyway, I added this item in the PostgreSQL 10 Open Items page under
"Design Decisions to Recheck Mid-Beta".  I'm willing to submit a patch for PG10.

Regards
Takayuki Tsunakawa




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] password_encryption, default and 'plain' support
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] May cause infinite loop when initializing rel-cachecontains partitioned table