Date: Wed, 20 Apr 2022 07:12:39 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Magnus Hagander <magnus@hagander.net>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	"Bossart, Nathan" <bossartn@amazon.com>,
	Fujii Masao <masao.fujii@oss.nttdata.com>,
	Justin Pryzby <pryzby@telsasoft.com>,
	Andres Freund <andres@anarazel.de>,
	Mark Dilger <mark.dilger@enterprisedb.com>,
	Don Seiler <don@seiler.us>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Estimating HugePages Requirements?
Message-ID: <Yl8z169DzkSjdZFV@paquier.xyz>
References: <YTmLQtpUSK77mlGT@paquier.xyz>
 <YTmMLtoLEAjMuRSm@paquier.xyz>
 <6AE0285D-0917-4C05-B6AA-4AEDD2FCBA52@amazon.com>
 <CABUevEweO_ZxTQox=QoO8e3rZQm9qFVU+zdoQvazTH9F7HpdEQ@mail.gmail.com>
 <20220314173417.GA1020555@nathanxps13>
 <Yi/82cqnpKkZsOjI@paquier.xyz>
 <CABUevExgoKMNveD5SvFWOYA4MQvPkDmGxY7DkVRASJED4gBYog@mail.gmail.com>
 <20220315224439.GA1133771@nathanxps13>
 <Yjq9bJe28newGZaK@paquier.xyz>
 <CABUevEyExSDrtZ4wU19iX4yvgExR1EpjFKB4ExFQDgTAvAHFyg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="d3ridMs2T0q+nH+S"
Content-Disposition: inline
In-Reply-To: 
 <CABUevEyExSDrtZ4wU19iX4yvgExR1EpjFKB4ExFQDgTAvAHFyg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/Yl8z169DzkSjdZFV%40paquier.xyz>
Precedence: bulk


--d3ridMs2T0q+nH+S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 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.=20

>> 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?
>=20
> 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.
--
Michael

--d3ridMs2T0q+nH+S
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmJfM9cACgkQnvQgOdby
QH1CrBAAp0sP8BTrrLIDG/OZqczCvKrauRpVGzBDXEOuVbCpvfzuX19JzBOI411p
VrTf09wiAZEzzdJKXiXKa4FooquW8D+FkFGodlRXJnwDM22/kx/TGnBnybaL5asb
eW1sZFuLVgUvprQcga5gm6wD/yAx2Yya3BU2U9zFvMcfx92GkrJyl0/lbRsKEIHg
C44nqlQd68KpnE2ufwoq9TIaLIyZ8gE2a2PfqgJllVoB/KBabMkAiRmOOPz3gmKF
HrHFvVwRdGyDQu3cUTsBqnBWo424Nl7Wa1zEY1+CUmqYXweZFka4Pf+9EhVOKqcz
D9P//HSl4fp3YvbTyYZ+y7Md5jhBOn3LbK2VcqoH3NgEOWOCmWdK2/UlLqTYhnEO
58wYV8kmd9Mgqjr5XLzvDfuD/ksscPLYdU9efAV7MW+a6fIm8vpL7O0D5Gfyy9H/
vYNATN1UPmQfaqsnYjRCgzW+Ei3/Qn91+Na3AidpVGRWJ7qFoA/mg/ewWHGQrxIX
lMiFUoEg4FTT2J+5bfZ5n1/nGNxiA4CSDI2cNAyIE75RuyTLTgJKrMV2SU3/RrZ8
JW7dcymcdg9K6fO2aEfH6fz9VhpNbC5qApCjI48Defd49gpoxj0lFMCfFn/Z5d3v
0cThhnXNBPi3BiWs3oNeHh7e0kJjfYQt2hDKd02RYMq/STVp1SQ=
=P5rA
-----END PGP SIGNATURE-----

--d3ridMs2T0q+nH+S--