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 1nhon1-0000YO-BX for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 08:37:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhon0-0005VN-5e for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 08:37:18 +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 1nhomz-0005Oy-O1 for pgsql-hackers@lists.postgresql.org; Fri, 22 Apr 2022 08:37:17 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nhomx-0004Ju-Af for pgsql-hackers@postgresql.org; Fri, 22 Apr 2022 08:37:16 +0000 Received: by mail-lf1-x130.google.com with SMTP id x17so13032835lfa.10 for ; Fri, 22 Apr 2022 01:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h3TzJvKRSz4CdE2o2YFD1D3OFj+z92yhWLNRH2WwQVk=; b=NUvWdJP3l+vmoPBdbnExGpfxZvskcn/2P5uepQT6lD6vfiM9VPgsBJDcVhlfpOqx4j k8fNKVpzFjp2le3/h+1eI5mm31yzbLo5yWY+Wd29KFRe0EYO055nHIb3EuNoXndpHXAx owejt+dM4zYvRosTA3uegA77mulfVAO+JI8p3tKr9+k0Vhret6hG/SnuQoD1MFveKKbl TwLbnyy/DpktPiQfx4Td+m8fAiU0XGeiToVdJmEoN2i8URG1n9aBNTGYF1Hrw6dRgCO6 /AunbOCM8+daN4fFNTzKgbv4o3iFvUTQcG2G2z/h5o19r5fn6LKmxLMNrD1j/u4TPmlh MN1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h3TzJvKRSz4CdE2o2YFD1D3OFj+z92yhWLNRH2WwQVk=; b=QQOt/E+6oRXg00+P8aeZYE1p/Ui30BRLiOiSrBQLcZiNVZoh304lWouyMpOvPmMZWz l2rh/aNuh7qhukZ+4NmjhuLlwKhxCyQN+VwU3J39Kf7maGrXGjtMltLk77MtSkJP35AN JHMPltLQFAbMtsog7QQRyTHga8X/fbYrl1opT+QgnX+HRdPCflzSAs3ufPFJljJl+k0j NFSiDX8ClqtpsiZeQIm51pV2CnjovkPvRZRq7tI1JgRC3Qhx4xpqWR8z219DL+ujEy/9 +cZT0qGp0wFPu9t3Ch1IQMZOIfmPA3EHxriLTGeLnrTPCNLzca3gQURr/OUCdQmLG1Lg nWPQ== X-Gm-Message-State: AOAM531QKNmu2eEAy9otGNlKMPAlWZuLfFgDBScdzg5EdPw+slGnj3ih sik/NDFXccmhWM3zCA5B/k13dsFWHccMQ9UKmnxEGQ== X-Google-Smtp-Source: ABdhPJxaDT3k7ilJajDUMBXBdCOmNyEekiH6J5wzPopyLiQQIKX4ksCPxbAogEklIxKIwgrYv1my+SHw2ZRW82628Wg= X-Received: by 2002:a05:6512:22d5:b0:471:8ba9:bd52 with SMTP id g21-20020a05651222d500b004718ba9bd52mr2312145lfu.227.1650616633556; Fri, 22 Apr 2022 01:37:13 -0700 (PDT) MIME-Version: 1.0 References: <6AE0285D-0917-4C05-B6AA-4AEDD2FCBA52@amazon.com> <20220314173417.GA1020555@nathanxps13> <20220315224439.GA1133771@nathanxps13> In-Reply-To: From: Magnus Hagander Date: Fri, 22 Apr 2022 09:49:34 +0200 Message-ID: Subject: Re: Estimating HugePages Requirements? To: Michael Paquier Cc: Nathan Bossart , "Bossart, Nathan" , Fujii Masao , Justin Pryzby , Andres Freund , Mark Dilger , Don Seiler , PostgreSQL-development Content-Type: multipart/alternative; boundary="0000000000001a936105dd3a22eb" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001a936105dd3a22eb Content-Type: text/plain; charset="UTF-8" On Wed, Apr 20, 2022, 00:12 Michael Paquier wrote: > On Thu, Mar 24, 2022 at 02:07:26PM +0100, Magnus Hagander wrote: > > But neither would the suggestion of redirecting stderr to /dev/null. > > In fact, doing the redirect it will *also* throw away any FATAL that > > happens. In fact, using the 2>/dev/null method, we *also* remove the > > message that says there's another postmaster running in this > > directory, which is strictly worse than the override of > > log_min_messages. > > Well, we could also tweak more the command with a redirection of > stderr to a log file or such, and tell to look at it for errors. > That's would be a pretty terrible ux though. > > That said, the redirect can be removed without recompiling postgres, > > so it is probably still hte better choice as a temporary workaround. > > But we should really look into getting a better solution in place once > > we start on 16. > > But do we really need a better or more invasive solution for already > running servers though? A SHOW command would be able to do the work > already in this case. This would lack consistency compared to the > offline case, but we are not without option either. That leaves the > case where the server is running, has allocated memory but is not > ready to accept connections, like crash recovery, still this use case > looks rather thin to me. I agree that thats a very narrow use case. And I'm nog sure the use case of a running server is even that important here - it's really the offline one that's important. Or rather, the really compelling one is when there is a server running but I want to check the value offline because it will change. SHOW doesn't help there because it shows the value based on the currently running configuration, not the new one after a restart. I don't agree that the redirect is a solution. It's a workaround. >> My solution for the docs is perhaps too confusing for the end-user, > >> and we are talking about a Linux-only thing here anyway. So, at the > >> end, I am tempted to just add the "2> /dev/null" as suggested upthread > >> by Nathan and call it a day. Does that sound fine? > > > > What would be a linux only thing? > > Perhaps not at some point in the future. Now that's under a section > of the docs only for Linux. > Hmm. So what's the solution on windows? I guess maybe it's not as important there because there is no limit on huge pages, but generally getting the expected shared memory usage might be useful? Just significantly less important. /Magnus --0000000000001a936105dd3a22eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 20, 2022, 00:12 Michael Paquier <michael@paquier.xyz> wrote:
On Thu, Mar 24, 2022 at 02:07:26PM +0100, = Magnus Hagander wrote:
> But neither would the suggestion of redirecting stderr to /dev/null. > In fact, doing the redirect it will *also* throw away any FATAL that > happens. In fact, using the 2>/dev/null method, we *also* remove th= e
> message that says there's another postmaster running in this
> directory, which is strictly worse than the override of
> log_min_messages.

Well, we could also tweak more the command with a redirection of
stderr to a log file or such, and tell to look at it for errors.

That's = would be a pretty terrible ux though.=C2=A0


=

> That said, the redirect can be removed without recompiling postgres, > so it is probably still hte better choice as a temporary workaround. > But we should really look into getting a better solution in place once=
> we start on 16.

But do we really need a better or more invasive solution for already
running servers though?=C2=A0 A SHOW command would be able to do the work already in this case.=C2=A0 This would lack consistency compared to the
offline case, but we are not without option either.=C2=A0 That leaves the case where the server is running, has allocated memory but is not
ready to accept connections, like crash recovery, still this use case
looks rather thin to me.


I agree that thats a very n= arrow use case. And I'm nog sure the use case of a running server is ev= en that important here - it's really the offline one that's importa= nt. Or rather, the really compelling one is when there is a server running = but I want to check the value offline because it will change. SHOW doesn= 9;t help there because it shows the value based on the currently running co= nfiguration, not the new one after a restart.=C2=A0
=
I don't agree that the redirect is a soluti= on. It's a workaround.=C2=A0


>> My solution for the docs is perhaps too confusing for the end-user= ,
>> and we are talking about a Linux-only thing here anyway.=C2=A0 So,= at the
>> end, I am tempted to just add the "2> /dev/null" as s= uggested upthread
>> by Nathan and call it a day.=C2=A0 Does that sound fine?
>
> What would be a linux only thing?

Perhaps not at some point in the future.=C2=A0 Now that's under a secti= on
of the docs only for Linux.
<= br>

Hmm. So what's t= he solution on windows? I guess maybe it's not as important there becau= se there is no limit on huge pages, but generally getting the expected shar= ed memory usage might be useful? Just significantly less important.=C2=A0

/Magnus=C2=A0

--0000000000001a936105dd3a22eb--