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 1pf6nz-0007fU-Dj for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Mar 2023 22:19:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pf6mz-0005fJ-Lk for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Mar 2023 22:18:37 +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 1pf6mz-0005fA-7q for pgsql-hackers@lists.postgresql.org; Wed, 22 Mar 2023 22:18:37 +0000 Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pf6mu-0001rJ-GZ for pgsql-hackers@postgresql.org; Wed, 22 Mar 2023 22:18:36 +0000 Received: by mail-io1-xd2b.google.com with SMTP id k17so9191582iob.1 for ; Wed, 22 Mar 2023 15:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; t=1679523510; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=68FRSPrBOSwGmfVpggvpCBkBi1PSh+9JpEEHcvzb3m8=; b=fiemBBNhy9iklPqe5Ll49EJhrSPnJVSAE7VK9VIr/3zQPzfJZUPP6FCeojjDQB24Cv ZoojSs6UnlLWwgx3/792KBTtCi7I33MaRb8rZwk76JRtkZsiWKYskQVpzZxFgu9PsV8C WLmpavYdNiZqacqMlYPhaZ4V3aFWoa6V2DRo9y9YU0KpnEuZig4eF4kFruCPEOsxiHHa 2Auye8dEVFiKEn7PHxKN/m43jWJVXY7ION/fPkgEqwzDNQtIlCMEZxBDQKqFVyw+pti0 LrnZ9rvzgqJMou8ozb8AXb9A2AlXwWnEU6btLIQy5tZi3iNTPPGaFcbVPKPPRxwEvcji x7dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679523510; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=68FRSPrBOSwGmfVpggvpCBkBi1PSh+9JpEEHcvzb3m8=; b=TVo09/nKV54QJQmx9NVWliIExoXyLyoTxuaM7xrwCKePmpVVSGcHUycyvV0bw0P1RB dS9ukNamZmV77G12ZAlV1EzkDL/meCtlOF+QSVaYtufz5ot7lxVTZpd2F3xb7pQ+QRab sZLquFQgZcC5m2MrZp90BvgyXd02UQaIVSAFmYBcR2tcFGAz0mVHqYVBgopOY4iakFPR KPfPBIFBdVY8JbsGd/ZOkd8/DbXxVYOzeEkv17b6DWfE5MXMYvhCZKakDArnj1IMNPTn kU9Sz6O/CgFTpHzFtW3q3+mN6LPmGumDY6oEGA7NUyOeM8kd787urRyo2s5iHVZFNQHr 43vA== X-Gm-Message-State: AO0yUKUIQYWMa+PSGt+H3T67Mw5EpeCRDw0nSFgabZum+mLjVFkN9rqO 5qh7V7ZtqnVVrKAyuhOaAQ1ldg== X-Google-Smtp-Source: AK7set8+OFz1Ogmh78PdsYpsWL/h7c2LXpu/apH6irEPwp3l6kKRdxw2KJovM/L4s+YP0LefNTI8+g== X-Received: by 2002:a5d:9299:0:b0:753:34ae:a00 with SMTP id s25-20020a5d9299000000b0075334ae0a00mr6041749iom.3.1679523510458; Wed, 22 Mar 2023 15:18:30 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id e41-20020a02862c000000b0039df8e7af39sm5578371jai.41.2023.03.22.15.18.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Mar 2023 15:18:29 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 95D9B8007F7; Wed, 22 Mar 2023 17:18:28 -0500 (CDT) Date: Wed, 22 Mar 2023 17:18:28 -0500 From: Justin Pryzby To: Michael Paquier Cc: Kyotaro Horiguchi , sfrost@snowman.net, alvherre@alvh.no-ip.org, andres@anarazel.de, nathandbossart@gmail.com, jchampion@timescale.com, john.naylor@enterprisedb.com, masao.fujii@oss.nttdata.com, noriyoshi.shinoda@hpe.com, pgsql-hackers@postgresql.org, rjuju123@gmail.com, sawada.mshk@gmail.com, tgl@sss.pgh.pa.us, thomas.munro@gmail.com Subject: Re: Improve logging when using Huge Pages Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Mar 22, 2023 at 04:37:01PM +0900, Michael Paquier wrote: > I have noted something.. For the WIN32 case, we have that: > > +++ b/src/backend/port/win32_shmem.c > @@ -327,6 +327,8 @@ retry: > Sleep(1000); > continue; > } > + > + huge_pages_active = ((flProtect & SEC_LARGE_PAGES) != 0); > break; > > Are you sure that this is correct? This is set in > PGSharedMemoryCreate(), part of CreateSharedMemoryAndSemaphores() in > the startup sequence that creates the shmem segment. However, for a > normal backend created by EXEC_BACKEND, SubPostmasterMain() reattaches > to an existing shared memory segment, so we don't go through the > creation path that would set huge_pages_active for the process just > started, (note that InitPostmasterChild() switches IsUnderPostmaster, > bypassing the shmem segment creation). Wow, good point. I think to make it work we'd need put huge_pages_active into BackendParameters and handle it in save_backend_variables(). If so, that'd be strong argument for using a GUC, which already has all the necessary infrastructure for exposing the server's state. -- Justin