public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Kyotaro Horiguchi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: Set huge_page_size on 32bit system
Date: Fri, 26 Jun 2026 17:16:23 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAMp4U1d177Jf9ZJwXGKom6APx3LSFATa=Z-M=N5kLzvTUcxutw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
On Fri, Jun 26, 2026 at 05:13:07PM +0900, Kyotaro Horiguchi wrote:
> At Fri, 26 Jun 2026 14:26:31 +0900, Michael Paquier <[email protected]> wrote in
>> So it seems to me that the mistake is that huge_page_size uses INT_MAX
>> as upper bound. We should use MAX_KILOBYTES instead; this definition
>> exists to exactly prevent this kind of computation mistake in 32b
>> environments.
>
> Ah, you're right. MAX_KILOBYTES exists for exactly this purpose.
Changing the states of the GUC tables in the stable branches would be
OK in this case. Now, it took so many years for somebody to complain
that setting huge pages at 1TB on a 32b build does not work that I
cannot really get excited about a backpatch. So I would just do the
switch on HEAD, and call it a day.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Set huge_page_size on 32bit system
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox