Be more careful about GucSource for internally-driven GUC settings.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 8 Jun 2022 17:26:18 +0000 (13:26 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 8 Jun 2022 17:26:18 +0000 (13:26 -0400)
commit7ab5b4eb483478bc85ad45ef5405b4a70c3f4c94
treeb38269a10a11233db2f1ae91d17d17eeaea3650d
parentabed46aea4739c78802ab2ce5e93dc9a7e23c113
Be more careful about GucSource for internally-driven GUC settings.

The original advice for hard-wired SetConfigOption calls was to use
PGC_S_OVERRIDE, particularly for PGC_INTERNAL GUCs.  However,
that's really overkill for PGC_INTERNAL GUCs, since there is no
possibility that we need to override a user-provided setting.
Instead use PGC_S_DYNAMIC_DEFAULT in most places, so that the
value will appear with source = 'default' in pg_settings and thereby
not be shown by psql's new \dconfig command.  The one exception is
that when changing in_hot_standby in a hot-standby session, we still
use PGC_S_OVERRIDE, because people felt that seeing that in \dconfig
would be a good thing.

Similarly use PGC_S_DYNAMIC_DEFAULT for the auto-tune value of
wal_buffers (if possible, that is if wal_buffers wasn't explicitly
set to -1), and for the typical 2MB value of max_stack_depth.

In combination these changes remove four not-very-interesting
entries from the typical output of \dconfig, all of which people
fingered as "why is that showing up?" in the discussion thread.

Discussion: https://postgr.es/m/3118455.1649267333@sss.pgh.pa.us
src/backend/access/transam/xlog.c
src/backend/bootstrap/bootstrap.c
src/backend/postmaster/postmaster.c
src/backend/storage/ipc/ipci.c
src/backend/utils/init/miscinit.c
src/backend/utils/init/postinit.c
src/backend/utils/misc/guc-file.l
src/backend/utils/misc/guc.c
src/include/utils/guc.h