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

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 also came up with another case where the current one won't work but it
> > could be really useful -- if we make a replication connection (with say
> > pg_receivewal) it would be good to be able to say "i want the master"
> (or "i
> > want a standby") the same way. And that will fail today if it needs SHOW
> to
> > work, right?
> >
> > So having it send that information across in the startup package when
> > talking to a 10 server, but falling back to using SHOW if talking to an
> > earlier server, would make a lot of sense I think.
>
> Of this reason, as libpq needs to be compliant with past server
> versions as well we are never going to save a set of version-dependent
> if/else code to handle target_session_attrs properly using either a
> SHOW or a new mechanism.
>

We'd have to cache the status recived yes. I don't see how that makes it a
"set of" if/else code when there is only one if/else now, though? Though
admittedly I haven't looked at the actual code for it.

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