On 2021/09/03 16:49, Kyotaro Horiguchi wrote:
> IF you are thinking to show that in GUC, you might want to look into
> the nearby thread [1]
Yes, let's discuss this feature at that thread.
> 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.
IMO, if the level is promoted to LOG, the message should be updated
so that it follows the error message style guide. But I agree that simpler
message would be better in this case. So what about something like
the following?
LOG: could not map anonymous shared memory (%zu bytes) with huge pages enabled
HINT: The server will map anonymous shared memory again with huge pages disabled.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION