Greetings,
* Fujii Masao (masao.fujii@gmail.com) wrote:
> On Tue, Oct 8, 2019 at 10:58 PM Stephen Frost <sfrost@snowman.net> wrote:
> > Having these options end up set but then hacking all of the other code
> > that looks at them to check if we're actually in recovery or not would
> > end up being both confusing to users as well as an ongoing source of
> > bugs (which has already been made clear by the fact that we're having
> > this discussion...). Wouldn't that also mean we would need to hack the
> > 'show' code, to blank out the recovery_target_name variable if we aren't
> > in recovery? Ugh.
>
> Isn't this overkill? This doesn't seem the problem only for recovery-related
> settings. We have already have the similar issue with other settings.
> For example, log_directory parameter is ignored when logging_collector is
> not enabled. But SHOW log_directory reports the setting value even when
> logging_collector is disabled. This seems the similar issue and might be
> confusing, but we could live with that.
I agree it's a similar issue. I disagree that it's actually sensible
for us to do so and would rather contend that it's confusing and not
good.
We certainly do a lot of smart things in PG, but showing the value of
variables that aren't accurate, and we *know* they aren't, hardly seems
like something we should be saying "this is good and ok, so let's do
more of this."
I'd rather argue that this just shows that we need to come up with a
solution in this area. I don't think it's *as* big of a deal when it
comes to logging_collector/log_directory because, at least there, you
don't even start to get into the same code paths where it matters, like
you end up doing with the recovery targets and crash recovery, so the
chances of bugs creeping in are less in the log_directory case.
I still don't think it's great though and, yes, would prefer that we
avoid having log_directory set when logging_collector is in use.
Thanks,
Stephen