Re: Improve logging when using Huge Pages
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>,
pgsql-hackers@postgresql.org, Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
"rjuju123@gmail.com" <rjuju123@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-09-16T15:12:39Z
Lists: pgsql-hackers
On 2021/09/07 22:16, Justin Pryzby wrote: > On Tue, Sep 07, 2021 at 07:12:36PM +0900, Fujii Masao wrote: >> One big concern about the patch is that log message is always reported >> when shared memory fails to be allocated with huge pages enabled >> when huge_pages=try. Since huge_pages=try is the default setting, >> many users would see this new log message whenever they start >> the server. Those who don't need huge pages but just use the default >> setting might think that such log messages would be noisy. > > I don't see this as any issue. We're only talking about a single message on > each restart, which would be added in a major release. I was afraid that logging the message like "could not ..." every time when the server starts up would surprise users unnecessarily. Because the message sounds like it reports a server error. So it might be good idea to change the message to something like "disabling huge pages" to avoid such surprise. > If it's a problem, the > message could be a NOTICE or INFO, and it won't be shown by default. That's an idea, but neither NOTICE nor INFO are suitable for this kind of message.... Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add GUC parameter "huge_pages_status"
- a14354cac0e3 17.0 landed
-
Add check on initial and boot values when loading GUCs
- a73952b79563 16.0 cited
-
Clean up some inconsistencies with GUC declarations
- d9d873bac670 16.0 cited
-
Clean up some GUC declarations and comments
- 7d25958453a6 16.0 cited