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 1nToaT-0005vC-4S for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Mar 2022 17:34:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nToaR-0008O8-W3 for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Mar 2022 17:34:27 +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 1nToaR-0008Nz-NV for pgsql-hackers@lists.postgresql.org; Mon, 14 Mar 2022 17:34:27 +0000 Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nToaN-0003nh-I6 for pgsql-hackers@postgresql.org; Mon, 14 Mar 2022 17:34:27 +0000 Received: by mail-pf1-x435.google.com with SMTP id g19so15173025pfc.9 for ; Mon, 14 Mar 2022 10:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FxKCVMxBsWCvFZB4CTv/8J3wCNJg7CuvD5nP8Mb1XiY=; b=f3lZULm5CdbxGzHX5NoxNmEqyzYEybmkjpV4aok4j3B4GDz3MN48GRjQgIVp1Uudpc 7y8vfwdew5fqV/kewXzUmoDa2EZ4K+IJp6Ux5NDnBejjAGHzfjbRFu+07UqSFuFLH0wL YV+MQSFkuxZWGxfGxqgbdEBUScESK4homjVtht+g99Ypf4GoftDiDj7LjnoBnQDFCkER MI/nFQ8iFCb3+lF03BwjXFAtdVzR9YkRcJuqZp/09aNfdjpLvDj3PpI1pouUFSY9vVYV OULjCvXFc5y8oi5AO7OHb0SnF+YTtniVrHAaJVgdL21aHuwNvwq3jNFDFbGMl4GM9Ijg 64lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FxKCVMxBsWCvFZB4CTv/8J3wCNJg7CuvD5nP8Mb1XiY=; b=uaJBz+2PfeuJysTJme6aP2Culjt5FZgV+43IQ/nu+Z/z4pYEKs4ZJyxMk/4/WrVF4S ELIqpno8ZpvHOKzYJdIgZAnnfj013UFME5ptizgakYE69nJdqCNmCnZLyw6p49cWLi5r 7haXJiRb+fK9Yeraz7dU1EdqjHHRqyPHch06YaEOMTH/hoJJ75I6Bsr36reKV+dvvD8L kLFVA5N7kV1I3GFs/VCcXJSskOr50XMrekQ6rVMP6J2RAZycKLshGf5jFPT0avVVN4YL d+S2LG/FCSGe0xYrQsxL0IgGX7dbcgVisSZnpwPr1L/Z4ZVSOAMD4lrv6Y4rQCFDxpIn r9dA== X-Gm-Message-State: AOAM531+wO4Yl7oWt2fjlFRhzoONFhDl/StO1aKpEfUlhEnfM/sfrCBh MJe3vkg0+/s+VUWJe2sf6/4= X-Google-Smtp-Source: ABdhPJz/y/CdIkenu5s2EwIzRbuxLM87xoUP6n0hcEjG9KZaIBkaPYtXmbrlhd0Fv8Y4tSAjEfV4OA== X-Received: by 2002:a63:10c:0:b0:36c:6dd0:44af with SMTP id 12-20020a63010c000000b0036c6dd044afmr20713228pgb.41.1647279261243; Mon, 14 Mar 2022 10:34:21 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id u10-20020a056a00124a00b004f741eb11d0sm22503475pfi.149.2022.03.14.10.34.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Mar 2022 10:34:20 -0700 (PDT) Date: Mon, 14 Mar 2022 10:34:17 -0700 From: Nathan Bossart To: Magnus Hagander Cc: "Bossart, Nathan" , Michael Paquier , Fujii Masao , Justin Pryzby , Andres Freund , Mark Dilger , Don Seiler , "pgsql-hackers@postgresql.org" Subject: Re: Estimating HugePages Requirements? Message-ID: <20220314173417.GA1020555@nathanxps13> References: <89EFD5FB-3C28-459C-9D6D-C9F93F7C2A54@amazon.com> <578A8F79-FD13-4408-865F-4D31EE5D8123@amazon.com> <4cc5b434-b174-9aae-197b-737db6cac4e3@oss.nttdata.com> <6AE0285D-0917-4C05-B6AA-4AEDD2FCBA52@amazon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 14, 2022 at 04:26:43PM +0100, Magnus Hagander wrote: > Nothing fixing this ended up actually getting committed, right? That > is, we still get the extra log output? Correct. > And in fact, the command documented on > https://www.postgresql.org/docs/devel/kernel-resources.html doesn't > actually produce the output that the docs show, it also shows the log > line, in the default config? If we can't fix the extra logging we > should at least have our docs represent reality -- maybe by adding a > "2>/dev/null" entry? But it'd be better to have it not output that log > in the first place... I attached a patch to adjust the documentation for now. This apparently crossed my mind earlier [0], but I didn't follow through with it for some reason. > (Of course what I'd really want is to be able to run it on a cluster > that's running, but that was discussed downthread so I'm not bringing > that one up for changes now) I think it is worth revisiting the extra logging and the ability to view runtime-computed GUCs on a running server. Should this be an open item for v15, or do you think it's alright to leave it for the v16 development cycle? [0] https://postgr.es/m/C45224E1-29C8-414C-A8E6-B718C07ACB94%40amazon.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com --fdj2RfSjLxBAspz7 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-send-stderr-to-dev-null-in-Linux-Huge-Pages-docum.patch"