Date: Fri, 3 Sep 2021 10:45:33 +0900
From: Michael Paquier <michael@paquier.xyz>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
	Andres Freund <andres@anarazel.de>,
	Magnus Hagander <magnus@hagander.net>,
	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: <YTF+PTIwtDghavEc@paquier.xyz>
References: <0D1645F3-ADFD-4B2F-9F34-961BDFBB881B@amazon.com>
 <YSmYq5Z4GAf8NzxM@paquier.xyz>
 <20210828035722.GQ26465@telsasoft.com>
 <82E1E183-691F-479E-B661-9BE8EC70BD21@amazon.com>
 <YSyIz86xUwpbP+LU@paquier.xyz>
 <48795AC4-289F-4CDE-88F5-4FD1ED2BD3DD@amazon.com>
 <YS8jgN37QvlrKnzQ@paquier.xyz>
 <298B6D88-7B71-4E1B-BFC4-E7BF3A32960D@amazon.com>
 <YTCCXOEdjbN9Sl+5@paquier.xyz>
 <23F67FC0-E432-4324-BEA4-F99B126510EA@amazon.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="T5y9rNg6J5Q9hZaa"
Content-Disposition: inline
In-Reply-To: <23F67FC0-E432-4324-BEA4-F99B126510EA@amazon.com>
Archived-At: 
 <https://www.postgresql.org/message-id/YTF%2BPTIwtDghavEc%40paquier.xyz>
Precedence: bulk


--T5y9rNg6J5Q9hZaa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 02, 2021 at 04:46:56PM +0000, Bossart, Nathan wrote:
> Yeah, huge_pages_required might not serve much purpose for Windows.
> We could always set it to -1 for Windows if it seems like it'll do
> more harm than good.

I'd be fine with this setup on environments where there is no need for
it.

>> At the end it would be nice to not finish with two GUCs.  Both depend
>> on the reordering of the actions done by the postmaster, so I'd be
>> curious to hear the thoughts of others on this particular point.
>=20
> Of course.  It'd be great to hear others' thoughts on this stuff.

Just to be clear here, the ordering of HEAD is that for the
postmaster:
- Load configuration.
- Handle -C config_param.
- checkDataDir(), to check permissions of the data dir, etc.
- checkControlFile(), to see if the control file exists.
- Switch to data directory as work dir.
- Lock file creation.
- Initial read of the control file (where the GUC data_checksums is
set).
- Register apply launcher
- shared_preload_libraries

With 0002, we have that:
- Load configuration.
- checkDataDir(), to check permissions of the data dir, etc.
- checkControlFile(), to see if the control file exists.
- Switch to data directory as work dir.
- Register apply launcher
- shared_preload_libraries
- Calculate the shmem GUCs (new step)
- Handle -C config_param.
- Lock file creation.
- Initial read of the control file (where the GUC data_checksums is
set).

One thing that would be incorrect upon more review is that we'd still
have data_checksums wrong with -C, meaning that the initial read of
the control file should be moved further up, and getting the control
file checks done before registering workers would be better.  Keeping
the lock file at the end would be fine AFAIK, but should we worry
about the interactions with _PG_init() here?

0001, that refactors the calculation of the shmem size into a
different routine, is fine as-is, so I'd like to move on and apply
it.
--
Michael

--T5y9rNg6J5Q9hZaa
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCAAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmExfj0ACgkQnvQgOdby
QH3O5w/+KO1tiJzz5R3nkzTDfGUoJn1vmOjkrSMxYEAygnYfhupnR5HZk5DwH7YQ
qVVmQ0CrWulPRanyrhhWnQaky/8vTszXyKlvgqDn7CtNOHqDXjw9Ck2wAa9qwtHv
I75uT3tIh3GC9/IjFcbtd609Y/Q/s285Xs2fxpaRqPxwqwANxBW1GDLsuGg54Fhr
/UrGA2HtlJ/6Ie78SOG7dD4kp4fd50ecDpP8bodH3PaS0qoy+KBqkxX/BuvB91T+
6CKN/WptbglAFdTBF5w2gO2RbmJUav2hTIDkupWANo519AM8HdWcPZk6owgrTBGG
4Gtct2795hgYq3BRSz9bRVdVi+fmyVYmHmMzPBcP547wLCMyfFt35P7lq2aAB2Ru
F9Tpun/heRwq6sUiR4omgrlKARDOXovGHexnlz/OzjS4CUAiAEY+pB7wPA/WeSPU
gEO8NMkjt0D/VXkV6K3oHQjssBeyIp3z5hx+5DTdnZ3ADDLRwyFbEu+MbDUys9X3
APff5RYrYn5CZOcBt68uBbs2ZSGS4iZjohajKBZpdZekwEvWutZJKHfUOdTkwNzy
Q1zMOC897t9/pN5Ttbdc+um6wzgPOY11G0mPPIx9XIDphFHMR6+UElNXiuG/aXw6
7xOgk0HpdOCXDkzeAIw2a1qJVdmrEe0TBGcE4G24XGB83YuyVeo=
=JdLH
-----END PGP SIGNATURE-----

--T5y9rNg6J5Q9hZaa--