Re: Improve logging when using Huge Pages
От | Fujii Masao |
---|---|
Тема | Re: Improve logging when using Huge Pages |
Дата | |
Msg-id | d928cc86-8e03-b481-18f7-2cb9c28fc724@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Improve logging when using Huge Pages (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: Improve logging when using Huge Pages
|
Список | pgsql-hackers |
On 2021/10/29 7:05, Justin Pryzby wrote: > 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. The log message should be reported even when huge_pages=off (and huge pages are not used)? Otherwise we cannot determine whether huge pages are actually used or not when no such log message is found in the server log. Or it's simpler and more intuitive to log the message "Anonymous shared memory was allocated with huge pages" only when huge pages are successfully requested? If that message is logged, we can determine that huge pages are used whatever the setting is. OTOH, if there is no such message, we can determine that huge pages are not used for some reasons, e.g., OS doesn't support huge pages, shared_memory_type is not set to mmap, etc. > + } 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. Agreed. > Should it include an errcode() ? > ERRCODE_INSUFFICIENT_RESOURCES ? > ERRCODE_OUT_OF_MEMORY ? Probably errcode is not necessary here because it's a log message not error one? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: