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