Fujii-san, Julien-san Thank you very much for your comment. I followed your comment and changed the elog function to ereport function and also changed the log level. The output message is the same as in the case of non-HugePages memory acquisition failure.I did not simplify the error messages as it would have complicated the response to the preprocessor.
> I agree that the message should be promoted to a higher level. But I > think we should also make that information available at the SQL level, > as the log files may be truncated / rotated before you need the info, > and it can be troublesome to find the information at the OS level, if > you're lucky enough to have OS access. In the attached patch, I have added an Internal GUC 'using_huge_pages' to know that it is using HugePages. This parameter will be True only if the instance is using HugePages. Regards, Noriyoshi Shinoda -----Original Message----- From: Fujii Masao [mailto:masao.fu...@oss.nttdata.com] Sent: Wednesday, September 1, 2021 2:06 AM To: Julien Rouhaud <rjuju...@gmail.com>; Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shin...@hpe.com> Cc: pgsql-hack...@postgresql.org Subject: Re: Improve logging when using Huge Pages On 2021/08/31 15:57, Julien Rouhaud wrote: > On Tue, Aug 31, 2021 at 1:37 PM Shinoda, Noriyoshi (PN Japan FSIP) > <noriyoshi.shin...@hpe.com> wrote: >> >> In the current version, when GUC huge_pages=try, which is the default >> setting, no log is output regardless of the success or failure of the >> HugePages acquisition. If you want to output logs, you need to set >> log_min_messages=DEBUG3, but it will output a huge amount of extra logs. >> With huge_pages=try setting, if the kernel parameter vm.nr_hugepages is not >> enough, the administrator will not notice that HugePages is not being used. >> I think it should output a log if HugePages was not available. +1 - elog(DEBUG1, "mmap(%zu) with MAP_HUGETLB failed, huge pages disabled: %m", + elog(WARNING, "mmap(%zu) with MAP_HUGETLB failed, huge pages +disabled: %m", elog() should be used only for internal errors and low-level debug logging. So per your proposal, elog() is not suitable here. Instead, ereport() should be used. The log level should be LOG rather than WARNING because this message indicates the information about server activity that administrators are interested in. The message should be updated so that it follows the Error Message Style Guide. https://www.postgresql.org/docs/devel/error-style-guide.html With huge_pages=on, if shared memory fails to be allocated, the error message is reported currently. Even with huge_page=try, this error message should be used to simplify the code as follows? errno = mmap_errno; - ereport(FATAL, + ereport((huge_pages == HUGE_PAGES_ON) ? FATAL : LOG, (errmsg("could not map anonymous shared memory: %m"), (mmap_errno == ENOMEM) ? errhint("This error usually means that PostgreSQL's request " > I agree that the message should be promoted to a higher level. But I > think we should also make that information available at the SQL level, > as the log files may be truncated / rotated before you need the info, > and it can be troublesome to find the information at the OS level, if > you're lucky enough to have OS access. +1 Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
huge_pages_log_v2.diff
Description: huge_pages_log_v2.diff
