Horton
Menu

Re: Improve logging when using Huge Pages

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: John Naylor <john.naylor@enterprisedb.com>, Thomas Munro <thomas.munro@gmail.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-07T15:56:16Z
Lists: pgsql-hackers 
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".

			regards, tom lane

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