Hello.

At Fri, 3 Sep 2021 06:28:58 +0000, "Shinoda, Noriyoshi (PN Japan FSIP)" 
<noriyoshi.shin...@hpe.com> wrote in 
> 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.

IF you are thinking to show that in GUC, you might want to look into
the nearby thread [1], especially about the behavior when invoking
postgres -C using_huge_pages.  (Even though the word "using" in the
name may suggest that the server is running, but I don't think it is
neat that the variable shows "no" by the command but shows "yes" while
the same server is running.)

I have some comment about the patch.

-               if (huge_pages == HUGE_PAGES_TRY && ptr == MAP_FAILED)
-                       elog(DEBUG1, "mmap(%zu) with MAP_HUGETLB failed, huge 
pages disabled: %m",
-                                allocsize);
+               if (ptr != MAP_FAILED)
+                       using_huge_pages = true;
+               else if (huge_pages == HUGE_PAGES_TRY)
+                       ereport(LOG,
+                                       (errmsg("could not map anonymous shared 
memory: %m"),
+                                        (mmap_errno == ENOMEM) ?
+                                        errhint("This error usually means that 
PostgreSQL's request "

If we set huge_pages to try and postgres falled back to regular pages,
it emits a large message relative to its importance. The user specifed
that "I'd like to use huge pages, but it's ok if not available.", so I
think the message should be far smaller.  Maybe just raising the
DEBUG1 message to LOG along with moving to ereport might be
sufficient.

-                               elog(DEBUG1, "CreateFileMapping(%zu) with 
SEC_LARGE_PAGES failed, "
-                                        "huge pages disabled",
-                                        size);
+                               ereport(LOG,
+                                               (errmsg("could not create 
shared memory segment: error code %lu", GetLastError()),
+                                                errdetail("Failed system call 
was CreateFileMapping(size=%zu, name=%s).",
+                                                                  size, 
szShareMem)));

It doesn't seem to be a regular user-facing message.  Isn't it
sufficient just to raise the log level to LOG?


[1] 
https://www.postgresql.org/message-id/20210903.141206.103927759882272221.horikyota.ntt%40gmail.com


Reply via email to