Re: Improve logging when using Huge Pages - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Improve logging when using Huge Pages
Date
Msg-id 20221109.114757.661491395677294771.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Improve logging when using Huge Pages  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Improve logging when using Huge Pages
List pgsql-hackers
At Tue, 8 Nov 2022 11:34:53 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in 
> On Tue, Nov 8, 2022 at 4:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > > On 2022-11-06 14:04:29 +0700, John Naylor wrote:
> > Agreed --- changing "on" to be exactly like "try" isn't an improvement.
> > If you want "try" semantics, choose "try".
> 
> Agreed, but how can we make the people who want a log message happy,
> without upsetting the people who don't want new log messages?  Hence
> my suggestion of a new level.  How about try_verbose?

Honestly I don't come up with other users of the new
log-level. Another possible issue is it might be a bit hard for people
to connect that level to huge_pages=try, whereas I think we shouldn't
put a description about the concrete impact range of that log-level.

I came up with an alternative idea that add a new huge_pages value
try_report or try_verbose, which tell postgresql to *always* report
the result of huge_pages = try.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Add connection active, idle time to pg_stat_activity
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Perform streaming logical transactions by background workers and parallel apply