RE: Improve logging when using Huge Pages

From: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi(dot)shinoda(at)hpe(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Jacob Champion <jchampion(at)timescale(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "Justin Pryzby" <pryzby(at)telsasoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Tom Lane <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: 2022-11-04 10:48:57
Message-ID: DM4PR84MB1734A6EE5103AB67F5F3B9F4EE3B9@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for your comment.
I understand that some people don't like noise log. However, I don't understand the feeling of disliking the one-line log that is output when the instance is started.
In both MySQL and Oracle Database, a log is output if it fails to acquire HugePages with the same behavior as huge_pages=try in PostgreSQL.

Regards,
Noriyoshi Shinoda

-----Original Message-----
From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Sent: Thursday, November 3, 2022 10:10 AM
To: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi(dot)shinoda(at)hpe(dot)com>
Cc: Jacob Champion <jchampion(at)timescale(dot)com>; Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>; Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>; Justin Pryzby <pryzby(at)telsasoft(dot)com>; PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>; Julien Rouhaud <rjuju123(at)gmail(dot)com>; Tom Lane <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

On Wed, Aug 3, 2022 at 8:42 PM Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi(dot)shinoda(at)hpe(dot)com> wrote:
> > As discussed in [1], we're taking this opportunity to return some patchsets that don't appear to be getting enough reviewer interest.
> Thank you for your helpful comments.
> As you say, my patch doesn't seem to be of much interest to reviewers either.
> I will discard the patch I proposed this time and consider it again.

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?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2022-11-04 11:41:33 Re: confirmed_flush_lsn shows LSN of the data that has not yet been received by the logical subscriber.
Previous Message Laurenz Albe 2022-11-04 10:46:03 Re: explain_regress, explain(MACHINE), and default to explain(BUFFERS) (was: BUFFERS enabled by default in EXPLAIN (ANALYZE))