Re: Standby accepts recovery_target_timeline setting?

Greetings,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Tue, Oct 8, 2019 at 9:58 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > From a user
> > perspective, what happens when you've started up PG as a primary, since
> > you don't have a signal file in place to indicate that you're doing
> > recovery, and you have a recovery_target set, so some user does
> > "show recovery_target_name" and sees a value? How is that sensible?
>
> I'd argue that not only is it sensible, but it's the only correct
> answer. If I put a value in postgresql.conf and it doesn't show up in
> the output of SHOW, I'm going to be confused. That just seems flat
> wrong to me.

You're going to be really confused when you realize that, sure, it's
set, but we just completely ignored it ...

How about we look at things like listen_addresses or shared_buffers?
Let's make a similar argument there- some day, in the future, we make PG
automagically realize when shared_buffers is too high to be able to
start up, so we lower it to some other value just to get the database
online, with the hope that the user will realize and fix the setting
(this isn't a joke- having shared_buffers be too high through an ALTER
SYSTEM setting is a real problem and it'd be nice if we had a way to
deal with that...), you think we should keep the shared_buffers variable
showing whatever was in the config file because, well, that's what was
in the config file?

If anything, what we should be doing here is throwing a WARNING or
similar that these settings don't make sense, because we aren't going
through recovery, and blank them out. If we want to be really cute, we
could have the show return something like: <not in recovery>, or
similar, but just returning an invalid value because that's what was in
the config file is nonsense. SHOW isn't a view of what's in
postgresql.conf, it's telling the user what the current system state is.

Thanks,

Stephen