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 1nYtGp-0007Ge-Or for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Mar 2022 17:35:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nYtGo-0003Wk-BP for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Mar 2022 17:35:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nYtGn-0003WZ-SB for pgsql-hackers@lists.postgresql.org; Mon, 28 Mar 2022 17:35:10 +0000 Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nYtGl-0003vr-GU for pgsql-hackers@postgresql.org; Mon, 28 Mar 2022 17:35:08 +0000 Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-ddfa38f1c1so15961003fac.11 for ; Mon, 28 Mar 2022 10:35:07 -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=0zJo9p9SIwKsyF3eAZwJeYxhqBFXydpk70IOAi6pHf0=; b=p9n08zZkZrRTCS4kVErqnnRz6kaH7/NyYxzuJO7BEuoqFG9XtjJkIYLZfldt/Sv3WB qYHEf+kkHa4m6vuYEuK+IFdRDD8z69x4YDGnO7AmTnuWgeAl6pp04QWSaGocfZ+Y5a5E v1iQJ57dQywU6ahY+qZ221kb+lsZUsBnxfF5RSnQadXMNNo9cFXMNwOu6MBuzrdHjJLe 7tlibwV6r7NpQqriIXsRNcnIq0Ys4RLQit3mxzdKNufwllrje9mw8JiS5SmGm3+iwj7L /l2ghN2eRJ2FZTuPG/ZlBpgSbROWRrb51fX2+tX10ZckZvsVoDG+kj6YAatUfp8r4M6V 9RoQ== 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=0zJo9p9SIwKsyF3eAZwJeYxhqBFXydpk70IOAi6pHf0=; b=oqqgXbqjF5R62yP054RR0plfEgwFyYwO1tQNYNWkFdA9Q6mTy8nq+qIJtH2e8prRzA 9DGQCn4Tx1BxsHji85WKI/eDFP3XPyekFY1Ruds6WjIwb07ZIu4r4iJgNrDzuV4oQrBt vAz121w/UEvwHcy6soGy6pbPHyVjjMj9+aSkd3ggbV9z8nyJ4NpRuFgLxvGMGhH7jzN6 KDji/a9GFDrf8HRBxH9T1Ee+IHxqK8qosg6l5LcaOQVV8PWqP6V95MsiJywVCml13FBk CCtZeAdULJ9dQ89ZZEP0Ct8Yw8TIJUrAGOGsp1qU5zEHfcUSNJFoMKMoEG+m+DTKor/P 8mPw== X-Gm-Message-State: AOAM5311mv13PDLXe4FjI1y7DIntl1trVK3iXDWiKJvqYRomdV1d23l2 +509Zj8uxlNybCgNJCU3ALA= X-Google-Smtp-Source: ABdhPJwivPTDC6kmERs1JWxLe5a5sAhpj/2fbG1zsqDPMx7IuAgSbltXfrdHgyCRlyBbZInk+U1xGQ== X-Received: by 2002:a05:6870:8327:b0:dd:b065:6a80 with SMTP id p39-20020a056870832700b000ddb0656a80mr122801oae.167.1648488906744; Mon, 28 Mar 2022 10:35:06 -0700 (PDT) Received: from nathanxps13 (162-195-170-173.lightspeed.stlsmo.sbcglobal.net. [162.195.170.173]) by smtp.gmail.com with ESMTPSA id w1-20020a056808090100b002da82caced5sm7264657oih.3.2022.03.28.10.35.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 10:35:05 -0700 (PDT) Date: Mon, 28 Mar 2022 10:35:03 -0700 From: Nathan Bossart To: Magnus Hagander Cc: Michael Paquier , "Bossart, Nathan" , Fujii Masao , Justin Pryzby , Andres Freund , Mark Dilger , Don Seiler , "pgsql-hackers@postgresql.org" Subject: Re: Estimating HugePages Requirements? Message-ID: <20220328173503.GA137769@nathanxps13> References: <6AE0285D-0917-4C05-B6AA-4AEDD2FCBA52@amazon.com> <20220314173417.GA1020555@nathanxps13> <20220315224439.GA1133771@nathanxps13> <20220324203108.GB1855897@nathanxps13> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <20220324203108.GB1855897@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 24, 2022 at 01:31:08PM -0700, Nathan Bossart wrote: > A couple of other options to consider: > > 1) Always set log_min_messages to WARNING/ERROR/FATAL for 'postgres -C'. > We might need some special logic for handling the case where the user is > inspecting the log_min_messages parameter. With this approach, you'd > probably never get extra output unless something was wrong (e.g., database > already running when inspecting a runtime-computed GUC). Also, this would > silence any extra output that you might see today with non-runtime-computed > GUCs. > > 2) Add some way to skip just the shutdown message (e.g., a variable set > when output_config_variable is true). With this approach, you wouldn't get > extra output by default, but you still might if log_min_messages is set to > something like DEBUG3. This wouldn't impact any extra output that you see > today with non-runtime-computed GUCs. I've attached a first attempt at option 1. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com --zYM0uCDKw75PZbzx Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v3-0001-Silence-extra-logging-with-postgres-C.patch"