public inbox for [email protected]
help / color / mirror / Atom feedFrom: Kyotaro Horiguchi <[email protected]>
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: Improve logging when using Huge Pages
Date: Tue, 14 Mar 2023 14:02:19 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAOuzzgqLTem0di9ascxepsKFHjKo11PnRyeB3-FaPhDQqGwLAw@mail.gmail.com>
References: <[email protected]>
<ZA+Bpk/[email protected]>
<CAOuzzgqLTem0di9ascxepsKFHjKo11PnRyeB3-FaPhDQqGwLAw@mail.gmail.com>
At Mon, 13 Mar 2023 21:33:31 +0100, Stephen Frost <[email protected]> wrote in
> > On Thu, Mar 09, 2023 at 03:02:29PM -0500, Stephen Frost wrote:
> > > * Justin Pryzby ([email protected]) wrote:
> > > Is there an agreement to use a function, instead ?
> >
> > Alvaro was -1 on using a function
>
>
> I don’t entirely get that argument (select thisfunc(); is much worse than
> show thisguc; ..? Also, the former is easier to use with other functions
> and such, as you don’t have to do current_setting(‘thisguc’)…).
>
> Andres is +0 (?)
>
>
> Kinda felt like this was closer to +0.5 or more, for my part anyway.
>
> Nathan is +1
> > Stephen is +1
> >
> > I'm -0.5,
>
>
> Why..?
IMHO, it appears that we use GUC "internal" variables to for the
lifespan-long numbers of a postmaster process or an instance.
Examples of such variables includes shared_memory_size and
s_m_s_in_huge_pages, integer_datetimes and data_checksums. I'm
uncertain about in_hot_standby, as it can change during a postmaster's
lifetime. However, pg_is_in_recovery() provides essentially the same
information.
Regarding huge_page_active, its value remains constant throughout a
postmaster's lifespan. In this regard, GUC may be a better fit for
this information. The issue with using GUC for this value is that the
postgres command cannot report the final value via the -C option,
which may be the reason for the third alternative "unknown".
I slightly prefer using a function for this, as if GUC is used, it can
only return "unknown" for the command "postgres -C
huge_page_active". However, apart from this advantage, I prefer using
a GUC for this information.
If we implement it as a function, I suggest naming it
"pg_huge_page_is_active" or something similar (the use of "is" is
signinficant here) to follow the naming convention used in
pg_is_in_recovery().
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
view thread (17+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Improve logging when using Huge Pages
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox