Re: Set huge_page_size on 32bit system

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: vilensipkdm(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Set huge_page_size on 32bit system
Date: 2026-06-26 08:16:23
Message-ID: aj41V5ACiv9OfkIF@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Jun 26, 2026 at 05:13:07PM +0900, Kyotaro Horiguchi wrote:
> At Fri, 26 Jun 2026 14:26:31 +0900, Michael Paquier <michael(at)paquier(dot)xyz> 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Laurenz Albe 2026-06-26 08:30:28 Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table
Previous Message Kyotaro Horiguchi 2026-06-26 08:13:07 Re: Set huge_page_size on 32bit system