At Mon, 13 Mar 2023 21:33:31 +0100, Stephen Frost <sfrost@snowman.net> wrote in
> > On Thu, Mar 09, 2023 at 03:02:29PM -0500, Stephen Frost wrote:
> > > * Justin Pryzby (pryzby@telsasoft.com) 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
