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

From John Naylor
Subject Re: Improve logging when using Huge Pages
Date
Msg-id CAFBsxsHKsdZjZfXVqxJMpFz4kFq82PsR1pKOEkGzLaeA6ONvnQ@mail.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
Re: Improve logging when using Huge Pages
List pgsql-hackers

On Thu, Nov 3, 2022 at 8:11 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> I wonder if the problem here is that people are reluctant to add noise
> to every starting system.   There are people who have not configured
> their system and don't want to see that noise, and then some people
> have configured their system and would like to know about it if it
> doesn't work so they can be aware of that, but don't want to use "off"
> because they don't want a hard failure.  Would it be better if there
> were a new level "try_log" (or something), which only logs a message
> if it tries and fails?

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. That way, both dev and prod can keep the same settings, since 'on' will have both visibility and robustness. I don't see a good reason to refuse to start -- seems like an anti-pattern.

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: remap the .text segment into huge pages at run time
Next
From: "Daniel Westermann (DWE)"
Date:
Subject: pg_upgrade, tables_with_oids.txt -> tables_with_oids.sql?