Re: Improve logging when using Huge Pages

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