Re: Improve logging when using Huge Pages

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi(dot)shinoda(at)hpe(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, masao(dot)fujii(at)oss(dot)nttdata(dot)com, rjuju123(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Subject: Re: Improve logging when using Huge Pages
Date: 2021-10-28 22:05:34
Message-ID: 20211028220534.GB31568@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Wed, Oct 27, 2021 at 06:39:46AM +0000, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
> Thank you for your comment.
> The attached patch stops message splitting.
> This patch also limits the timing of message output when huge_pages = try and HugePages is not used.

Thanks for updating the patch.

I hope we've debated almost everything about its behavior, and it's nearly
ready :)

+ } else if (!with_hugepages && huge_pages == HUGE_PAGES_TRY)
+ ereport(LOG, (errmsg("Anonymous shared memory was allocated without huge pages.")));

I would write this as a separate "if". The preceding block is a terminal FATAL
and it seems more intuitive that way. But it's up to you (and the committer).

The errmsg() text should not be capitalized and not end with a period.
https://www.postgresql.org/docs/devel/error-style-guide.html

The parenthesis around (errmsg()) are not required since 18 months ago
(e3a87b499). Since this change won't be backpatched, I think it's better to
omit them.

Should it include an errcode() ?
ERRCODE_INSUFFICIENT_RESOURCES ?
ERRCODE_OUT_OF_MEMORY ?

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-10-28 22:07:48 Re: inefficient loop in StandbyReleaseLockList()
Previous Message Zhihong Yu 2021-10-28 21:22:52 Re: dummy relation in partitionwise join