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

2017-10-02 Thread Daniel Gustafsson
> On 22 Sep 2017, at 18:57, Melanie Plageman wrote: > > On Tue, Sep 19, 2017 at 4:15 PM, Melanie Plageman > wrote: > The latest patch applies cleanly and builds (I am also seeing the failing TAP > tests),

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

2017-09-22 Thread Melanie Plageman
On Tue, Sep 19, 2017 at 4:15 PM, Melanie Plageman wrote: > > The latest patch applies cleanly and builds (I am also seeing the failing > TAP tests), however, I have a concern. With a single server set up, when I > attempt to make a connection with

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

2017-09-19 Thread Melanie Plageman
On Tue, Sep 12, 2017 at 6:11 PM, Thomas Munro wrote: > On Wed, Sep 13, 2017 at 3:48 AM, Elvis Pranskevichus > wrote: > > I incorporated those bits into your patch and rebased in onto master. > > Please see attached. > > > > FWIW, I think that

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

2017-09-12 Thread Thomas Munro
On Wed, Sep 13, 2017 at 3:48 AM, Elvis Pranskevichus wrote: > I incorporated those bits into your patch and rebased in onto master. > Please see attached. > > FWIW, I think that mixing the standby status and the default > transaction writability is suboptimal. They are

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

2017-09-12 Thread Elvis Pranskevichus
On Wednesday, May 24, 2017 9:38:36 PM EDT Tsunakawa, Takayuki wrote: > The clients will know the change of session_read_only when they do > something that calls RecoveryInProgress(). Currently, > RecoveryInProgress() seems to be the only place where the sessions > notice the promotion, so I set

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

2017-08-24 Thread Michael Banck
Hi, On Wed, May 24, 2017 at 07:16:06AM +, Tsunakawa, Takayuki wrote: > I confirmed that the attached patch successfully provides: I was going to take a look at this, but the patch no longer applies cleanly for me: Hunk #1 succeeded at 1474 (offset 49 lines). Hunk #2 succeeded at 1762

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

2017-05-24 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > I didn't look at exactly how you tried to do that, but GUCs whose values > depend on other GUCs generally don't work well at all. transaction_read_only and transaction_isolation depends

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

2017-05-24 Thread Tsunakawa, Takayuki
From: Robert Haas [mailto:robertmh...@gmail.com] > 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

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

2017-05-24 Thread Tom Lane
Robert Haas writes: > On Wed, May 24, 2017 at 3:16 AM, Tsunakawa, Takayuki > wrote: >> For this, I added a GUC_REPORT variable session_read_only which indicates >> the session's default read-only status. The characteristics are: >> >> *

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

2017-05-24 Thread Robert Haas
On Wed, May 24, 2017 at 3:16 AM, Tsunakawa, Takayuki 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

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

2017-05-24 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > On 13 April 2017 at 14:59, Tsunakawa, Takayuki > wrote: > > > 2. Make transaction_read_only GUC_REPORT This is to avoid the added > > round-trip by

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

2017-05-08 Thread Tsunakawa, Takayuki
From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > On 13 April 2017 at 14:59, Tsunakawa, Takayuki > wrote: > > > 2. Make transaction_read_only GUC_REPORT This is to avoid the added > > round-trip by

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

2017-04-13 Thread Craig Ringer
On 13 April 2017 at 14:59, Tsunakawa, Takayuki 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

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

2017-04-13 Thread Tsunakawa, Takayuki
Hello, I didn't realize that my target_session_attrs naming proposal was committed. I didn't think half way it would be adopted, because the name is less intuitive than the original target_server_type, and is different from the PgJDBC's targetServerType. From:

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

2017-04-12 Thread Magnus Hagander
On Wed, Apr 12, 2017 at 2:36 PM, Robert Haas wrote: > On Tue, Apr 11, 2017 at 4:05 AM, Magnus Hagander > wrote: > > On Tue, Apr 11, 2017 at 3:26 AM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Mon, Apr 10, 2017 at 5:47 PM, Magnus

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

2017-04-12 Thread Robert Haas
On Tue, Apr 11, 2017 at 4:05 AM, Magnus Hagander wrote: > On Tue, Apr 11, 2017 at 3:26 AM, Michael Paquier > wrote: >> On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander >> wrote: >> > Based on that we seem to agree here,

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

2017-04-12 Thread Magnus Hagander
On Tue, Apr 11, 2017 at 2:38 PM, Simon Riggs wrote: > On 11 April 2017 at 09:05, Magnus Hagander wrote: > > On Tue, Apr 11, 2017 at 3:26 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> > >> On Mon, Apr 10, 2017 at 5:47 PM, Magnus

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

2017-04-11 Thread Simon Riggs
On 11 April 2017 at 09:05, Magnus Hagander wrote: > On Tue, Apr 11, 2017 at 3:26 AM, Michael Paquier > wrote: >> >> On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander >> wrote: >> > Based on that we seem to agree here, should we

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

2017-04-11 Thread Magnus Hagander
On Tue, Apr 11, 2017 at 3:26 AM, Michael Paquier wrote: > On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander > wrote: > > Based on that we seem to agree here, should we add this as an open item? > > Clearly if we want to change this, we should do so

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

2017-04-10 Thread Michael Paquier
On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander wrote: > Based on that we seem to agree here, should we add this as an open item? > Clearly if we want to change this, we should do so before 10. This really is a new feature, so as the focus is to stabilize things I think

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

2017-04-10 Thread Magnus Hagander
On Wed, Apr 5, 2017 at 6:22 PM, Robert Haas wrote: > On Thu, Mar 23, 2017 at 4:50 AM, Magnus Hagander > wrote: > > One thing we might want to consider around this -- in 10 we have > > target_session_attrs=read-write (since > >

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

2017-04-05 Thread Robert Haas
On Thu, Mar 23, 2017 at 4:50 AM, Magnus Hagander wrote: > One thing we might want to consider around this -- in 10 we have > target_session_attrs=read-write (since > 721f7bd3cbccaf8c07cad2707826b83f84694832), which will issue a SHOW > transaction_read_only on the connection.

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

2017-03-23 Thread Elvis Pranskevichus
On Thursday, March 23, 2017 4:50:20 AM EDT Magnus Hagander wrote: > We should probably consider if there is some way we can implement > these two things the same way. If we're inventing a new variable that > gets pushed on each connection, perhaps we can use that one and avoid > the SHOW command?

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

2017-03-23 Thread Magnus Hagander
On Wed, Mar 22, 2017 at 9:00 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/22/17 14:09, Robert Haas wrote: > >> The opposite means primary. I can flip the GUC name to "is_primary", if > >> that's clearer. > > Hmm, I don't find that clearer. "hot standby" has a very

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

2017-03-22 Thread Elvis Pranskevichus
On Wednesday, March 22, 2017 4:28:18 PM EDT Robert Haas wrote: > On Wed, Mar 22, 2017 at 4:00 PM, Peter Eisentraut > > I think we could use "in_recovery", which would be consistent with > > existing naming. > > True. Ironically, that was the name I originally used. I'll update the patch. >

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

2017-03-22 Thread Robert Haas
On Wed, Mar 22, 2017 at 4:00 PM, Peter Eisentraut wrote: > On 3/22/17 14:09, Robert Haas wrote: >>> The opposite means primary. I can flip the GUC name to "is_primary", if >>> that's clearer. >> Hmm, I don't find that clearer. "hot standby" has a very specific

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

2017-03-22 Thread Peter Eisentraut
On 3/22/17 14:09, Robert Haas wrote: >> The opposite means primary. I can flip the GUC name to "is_primary", if >> that's clearer. > Hmm, I don't find that clearer. "hot standby" has a very specific > meaning; "primary" isn't vague, but I would say it's less specific. The problem I have is that

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

2017-03-22 Thread Elvis Pranskevichus
On Wednesday, March 22, 2017 2:17:27 PM EDT Jaime Casanova wrote: > On 18 March 2017 at 14:01, Elvis Pranskevichus wrote: > > On Saturday, March 18, 2017 3:33:16 AM EDT Michael Paquier wrote: > >> Why adding a good chunk of code instead of using > >> pg_is_in_recovery(), > >>

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

2017-03-22 Thread Jaime Casanova
On 18 March 2017 at 14:01, Elvis Pranskevichus wrote: > On Saturday, March 18, 2017 3:33:16 AM EDT Michael Paquier wrote: >> >> Why adding a good chunk of code instead of using pg_is_in_recovery(), >> which switches to false once a server exits recovery? > > That requires

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

2017-03-22 Thread Robert Haas
On Wed, Mar 22, 2017 at 8:25 AM, Elvis Pranskevichus wrote: > On Tuesday, March 21, 2017 11:50:38 PM EDT Peter Eisentraut wrote: >> On 3/17/17 13:56, Elvis Pranskevichus wrote: >> > Currently, clients wishing to know when the server exits hot standby >> > have to resort to

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

2017-03-22 Thread Elvis Pranskevichus
On Tuesday, March 21, 2017 11:50:38 PM EDT Peter Eisentraut wrote: > On 3/17/17 13:56, Elvis Pranskevichus wrote: > > Currently, clients wishing to know when the server exits hot standby > > have to resort to polling, which is often suboptimal. > > > > This adds the new "in_hot_standby" GUC

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

2017-03-21 Thread Peter Eisentraut
On 3/17/17 13:56, Elvis Pranskevichus wrote: > Currently, clients wishing to know when the server exits hot standby > have to resort to polling, which is often suboptimal. > > This adds the new "in_hot_standby" GUC variable that is reported via a > ParameterStatus message. The terminology chosen

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

2017-03-18 Thread Elvis Pranskevichus
On Saturday, March 18, 2017 3:33:16 AM EDT Michael Paquier wrote: > On Sat, Mar 18, 2017 at 2:56 AM, Elvis Pranskevichus wrote: > > Currently, clients wishing to know when the server exits hot standby > > have to resort to polling, which is often suboptimal. > > > > This adds

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

2017-03-18 Thread Michael Paquier
On Sat, Mar 18, 2017 at 2:56 AM, Elvis Pranskevichus wrote: > Currently, clients wishing to know when the server exits hot standby > have to resort to polling, which is often suboptimal. > > This adds the new "in_hot_standby" GUC variable that is reported via a >

[HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

2017-03-17 Thread Elvis Pranskevichus
Hi, Currently, clients wishing to know when the server exits hot standby have to resort to polling, which is often suboptimal. This adds the new "in_hot_standby" GUC variable that is reported via a ParameterStatus message. This allows the clients to: (a) know right away that they are