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

From Tom Lane
Subject Re: How about a psql backslash command to show GUCs?
Date
Msg-id 816940.1649782841@sss.pgh.pa.us
Whole thread Raw
In response to Re: How about a psql backslash command to show GUCs?  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: How about a psql backslash command to show GUCs?  ("Jonathan S. Katz" <jkatz@postgresql.org>)
List pgsql-hackers
"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 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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: How about a psql backslash command to show GUCs?
Next
From: Andres Freund
Date:
Subject: Re: make MaxBackends available in _PG_init