Horton
Menu

Re: Improve logging when using Huge Pages

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, John Naylor <john.naylor@enterprisedb.com>, "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>, Jacob Champion <jchampion@timescale.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Justin Pryzby <pryzby@telsasoft.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Julien Rouhaud <rjuju123@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2022-11-07T22:34:53Z
Lists: pgsql-hackers 
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:
> >> I think the best thing to do is change huge_pages='on' to log a WARNING and
> >> fallback to regular pages if the mapping fails.
>
> > I am strongly opposed to making 'on' fall back to not using huge pages. That's
> > what 'try' is for.
>
> 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?

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add GUC parameter "huge_pages_status"

  2. Add check on initial and boot values when loading GUCs

  3. Clean up some inconsistencies with GUC declarations

  4. Clean up some GUC declarations and comments