Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mha76-0004TH-Te for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Nov 2021 16:24:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mha75-0002ps-SO for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Nov 2021 16:24:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mha75-0002pj-Jl for pgsql-hackers@lists.postgresql.org; Mon, 01 Nov 2021 16:24:47 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mha6y-0003ys-Rr for pgsql-hackers@postgresql.org; Mon, 01 Nov 2021 16:24:47 +0000 Received: from hrk.local (p2388012-ipbf1027funabasi.chiba.ocn.ne.jp [118.6.6.12]) by oss.nttdata.com (Postfix) with ESMTPSA id 2A55260902; Tue, 2 Nov 2021 01:24:37 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.3 at oss.nttdata.com Subject: Re: Improve logging when using Huge Pages To: Justin Pryzby , "Shinoda, Noriyoshi (PN Japan FSIP)" Cc: pgsql-hackers@postgresql.org, rjuju123@gmail.com, tgl@sss.pgh.pa.us, Kyotaro Horiguchi References: <80872660-ad16-3040-0a25-bd741faa5fc0@oss.nttdata.com> <20210922002322.GS831@telsasoft.com> <20210927.114023.1519840069762071193.horikyota.ntt@gmail.com> <20211022023815.GI741@telsasoft.com> <20211028220534.GB31568@telsasoft.com> From: Fujii Masao Message-ID: Date: Tue, 2 Nov 2021 01:24:36 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211028220534.GB31568@telsasoft.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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