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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Elvis Pranskevichus <elprans(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Date: 2017-04-12 14:24:56
Message-ID: CABUevEwrEBWDfB3t3z6kSfTaZ=7fN53JkA22mKBhcRdqUnjAxQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 12, 2017 at 2:36 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Apr 11, 2017 at 4:05 AM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> > On Tue, Apr 11, 2017 at 3:26 AM, Michael Paquier <
> michael(dot)paquier(at)gmail(dot)com> wrote:
> >> On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander <magnus(at)hagander(dot)net>
> >> 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 that we should not make the code more complicated because...
> >
> > The part I'm talking about is the potential adjustment of the patch
> that's
> > already committed. That's not a new feature, that's exactly the sort of
> > thing we'd want to adjust before we get to release. Because once
> released we
> > really can't change it.
>
> I don't really agree. I think if we go and install a GUC_REPORT GUC
> now, we're much less likely to flush out the bugs in the 'show
> transaction_read_only' mechanism. Also, now that I think about, the
> reason why we settled on 'show transaction_read_only' against
> alternate queries is because there's some ability for the DBA to make
> that return 'false' rather than 'true' even when not in recovery, so
> that if for example you are using logical replication rather than
> physical replication, you have a way to make
> target_session_attrs=read-write still do something useful. If you add
> an in_hot_standby GUC that's used instead, you lose that.
>
> Now, we can decide what we want to do about that, but I don't see that
> a change in this area *must* go into v10. Maybe the answer is that
> target_session_attrs grows additional values like 'primary' and
> 'standby' alongside 'read-write' (and Simon's suggested 'read-only').
> Or maybe we have another idea. But I don't really see the urgency of
> whacking this around right this minute. There's nothing broken here;
> there's just more stuff people would like to have. It can be added
> next time around.
>
>
Fair enough, sounds reasonable. I wasn't engaged in the original thread, so
you clearly have thought about this more than I have. I just wanted to make
sure we're not creating something that's going to cause a head-ache for
such a feature in the future.

(And this is why I was specifically asking you if you wanted it on the open
items list or not!)

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-04-12 14:46:38 Re: Interval for launching the table sync worker
Previous Message Tom Lane 2017-04-12 14:24:30 Re: index-only count(*) for indexes supporting bitmap scans