Re: How about a psql backslash command to show GUCs? - Mailing list pgsql-hackers

From Jonathan S. Katz
Subject Re: How about a psql backslash command to show GUCs?
Date
Msg-id a93f754c-e020-b330-9104-d8f3ce6ea654@postgresql.org
Whole thread Raw
In response to Re: How about a psql backslash command to show GUCs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: How about a psql backslash command to show GUCs?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 4/12/22 1:00 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On 4/12/22 11:19 AM, Tom Lane wrote:
>>> It'd just look like this, I think.  I see from looking at guc.c that
>>> boot_val can be NULL, so we'd better use IS DISTINCT FROM.
> 
>> I tested it and I like this a lot better, at least it's much more
>> consolidated. They all seem to be generated (directories, timezones,
>> collations/encodings).
> 
> Yeah, most of what shows up in a minimally-configured installation is
> postmaster-computed settings like config_file, rather than things
> that were actually set by the DBA.  Personally I'd rather hide the
> ones that have source = 'override', but that didn't seem to be the
> consensus.

The list seems more reasonable now, though now that I'm fully in the 
"less is more" camp based on the "non-defaults" description, I think 
anything we can do to further prune is good.

>> The one exception to this seems to be "max_stack_depth", which is
>> rendering on my "\dconfig" though I didn't change it, an it's showing
>> it's default value of 2MB. "boot_val" says 100, "reset_val" says 2048,
>> and it's commented out in my postgresql.conf. Do we want to align that?
> 
> I don't think there's any principled thing we could do about that in
> psql.  The boot_val is a conservatively small 100kB, but we crank
> that up automatically based on getrlimit(RLIMIT_STACK), so on any
> reasonable platform it's going to show as not being default.

Got it.

We may be at a point where it's "good enough" and let more people chime 
in during beta.

Thanks,

Jonathan

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: Nathan Bossart
Date:
Subject: Re: make MaxBackends available in _PG_init