Date: Wed, 15 Feb 2023 10:13:17 -0800
From: Nathan Bossart <nathandbossart@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Andres Freund <andres@anarazel.de>,
	Michael Paquier <michael@paquier.xyz>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>, thomas.munro@gmail.com,
	tgl@sss.pgh.pa.us, john.naylor@enterprisedb.com,
	noriyoshi.shinoda@hpe.com, jchampion@timescale.com,
	sawada.mshk@gmail.com, masao.fujii@oss.nttdata.com,
	pgsql-hackers@postgresql.org, rjuju123@gmail.com
Subject: Re: Improve logging when using Huge Pages
Message-ID: <20230215181317.GA1353037@nathanxps13>
References: <20230208231803.GP1653@telsasoft.com>
 <20230209094013.67varf63bihops33@alvherre.pgsql>
 <20230209192909.GA606606@nathanxps13>
 <20230213232245.GI1653@telsasoft.com>
 <20230214041852.GA1190218@nathanxps13>
 <20230215013256.GP1653@telsasoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230215013256.GP1653@telsasoft.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20230215181317.GA1353037%40nathanxps13>
Precedence: bulk

On Tue, Feb 14, 2023 at 07:32:56PM -0600, Justin Pryzby wrote:
> On Mon, Feb 13, 2023 at 08:18:52PM -0800, Nathan Bossart wrote:
>> On Mon, Feb 13, 2023 at 05:22:45PM -0600, Justin Pryzby wrote:
>> nitpick: Does this need to be initialized here?
> 
> None of the GUCs' C vars need to be initialized, since the guc machinery
> will do it. 
> 
> ...but the convention is that they *are* initialized - and that's now
> partially enforced.
> 
> See:
> d9d873bac67047cfacc9f5ef96ee488f2cb0f1c3
> 7d25958453a60337bcb7bcc986e270792c007ea4
> a73952b795632b2cf5acada8476e7cf75857e9be

I see.  This looked a little strange to me because many of the other
variables are uninitialized.  In a73952b, I see that we allow the variables
for string GUCs to be initialized to NULL.  Anyway, this is only a nitpick.
I don't feel strongly about it.

>> I'm curious why you chose to make this a string instead of an enum.  There
>> might be little practical difference, but since there are only three
>> possible values, I wonder if it'd be better form to make it an enum.
> 
> It takes more code to write as an enum - see 002.txt.  I'm not convinced
> this is better.
> 
> But your comment made me fix its <type>, and reconsider the strings,
> which I changed to active={unknown/true/false} rather than {unk/on/off}.
> It could also be active={unknown/yes/no}...

I think unknown/true/false is fine.  I'm okay with using a string if no one
else thinks it should be an enum (or a bool).

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com