Re: Improve logging when using Huge Pages

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