Re: Standby accepts recovery_target_timeline setting?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, David Steele <david(at)pgmasters(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Standby accepts recovery_target_timeline setting?
Date: 2019-10-09 13:57:10
Message-ID: CA+TgmobB981ikUcnqjvpR61jPf3j-ghEGGfMyj2OwODvZDVSJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 9, 2019 at 8:42 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> You're going to be really confused when you realize that, sure, it's
> set, but we just completely ignored it ...

No, I'm not, because I expect that settings will only take effect for
operations to which they apply. As Fujii Masao also pointed out, there
are lots of other settings that are ignored (but still shown as set)
in situations where they don't apply.

> 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?

Yes. I mean, I assume that if we did such a thing, we might rename the
GUC in the config file to max_shared_buffers or shared_buffers_limit
or something like that to make it more clear, and shared_buffers
itself might become a PGC_INTERNAL setting that users can't modify but
which can still be viewed using SHOW. But if a value is set in the
configuration file and not overridden somewhere else (ALTER USER,
ALTER FUNCTION, etc.) I expect the SHOW command to display that value.

> 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.

SHOW is telling the user the value that is configured in the current
session, which may or may not be the value configured in
postgresql.conf, but is the value that was configured somewhere. For
the most part, it's not trying to tell the user what the current
system state is, although we have a few weird exceptions that behave
otherwise.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-10-09 13:59:07 Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12
Previous Message Stephen Frost 2019-10-09 13:37:34 Re: pgsql: Remove pqsignal() from libpq's official exports list.