Horton

Thread

Commits

  1. Switch maximum of GUC huge_page_size to MAX_KILOBYTES

  1. Set huge_page_size on 32bit system

    Daria Shanina <vilensipkdm@gmail.com> — 2026-06-25T14:54:46Z

    Hi all,

I found an error: on 32bit system (I tested on Debian 6.1.0-32-686-pae #1
SMP PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) i686 GNU/Linux) when we
set huge_page_size = 1 TB postgres process fails with signal SIGFPE when
calculated hugepagesize_local = (Size) huge_page_size * 1024; the value
exceeds max for unsigned int = (2^32 – 1).
I attached a full backtrace and one small fix.

What do you think about this?
Thank you for your attention!

--
Best regards,
Daria Shanina

  2. Re: Set huge_page_size on 32bit system

    Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2026-06-26T04:24:15Z

    Hello,

At Thu, 25 Jun 2026 17:54:46 +0300, Daria Shanina <vilensipkdm@gmail.com> wrote in 
> Hi all,
> 
> I found an error: on 32bit system (I tested on Debian 6.1.0-32-686-pae #1
> SMP PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) i686 GNU/Linux) when we
> set huge_page_size = 1 TB postgres process fails with signal SIGFPE when
> calculated hugepagesize_local = (Size) huge_page_size * 1024; the value
> exceeds max for unsigned int = (2^32 – 1).
> I attached a full backtrace and one small fix.

Good catch.

> What do you think about this?
> Thank you for your attention!

This would avoid the SIGFPE, but I wonder whether this should be
rejected earlier in check_huge_page_size() instead, with an error
like:

> "huge_page_size" is too large for this platform.

We could also make the later calculation use a wider integer type, but
such a value would not be usable anyway on a platform where it does
not fit in Size.  So it seems better to reject it earlier in
check_huge_page_size(), before reaching CreateAnonymousSegment().

Regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  3. Re: Set huge_page_size on 32bit system

    Michael Paquier <michael@paquier.xyz> — 2026-06-26T05:26:31Z

    On Fri, Jun 26, 2026 at 01:24:15PM +0900, Kyotaro Horiguchi wrote:
> We could also make the later calculation use a wider integer type, but
> such a value would not be usable anyway on a platform where it does
> not fit in Size.  So it seems better to reject it earlier in
> check_huge_page_size(), before reaching CreateAnonymousSegment().

The top of guc.h includes the following thing:
/*
 * Maximum for integer GUC variables that are measured in kilobytes of memory.
 * This value is chosen to ensure that the corresponding number of bytes fits
 * into a variable of type size_t or ssize_t.  Be sure to compute the number
 * of bytes like "guc_var * (Size) 1024" to avoid int-width overflow.
 */
#if SIZEOF_SIZE_T > 4
#define MAX_KILOBYTES	INT_MAX
#else
#define MAX_KILOBYTES	(INT_MAX / 1024)
#endif

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.
--
Michael

  4. Re: Set huge_page_size on 32bit system

    Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2026-06-26T08:13:07Z

    At Fri, 26 Jun 2026 14:26:31 +0900, Michael Paquier <michael@paquier.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.

Regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  5. Re: Set huge_page_size on 32bit system

    Michael Paquier <michael@paquier.xyz> — 2026-06-26T08:16:23Z

    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@paquier.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

  6. Re: Set huge_page_size on 32bit system

    Michael Paquier <michael@paquier.xyz> — 2026-06-27T02:50:05Z

    On Fri, Jun 26, 2026 at 05:16:23PM +0900, Michael Paquier wrote:
> 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.

And just applied a patch doing so, HEAD-only.
--
Michael

  7. Re: Set huge_page_size on 32bit system

    Daria Shanina <vilensipkdm@gmail.com> — 2026-06-30T13:23:59Z

    Hello,
Kiyotaro and Michael, thank you so much for your answers!
Using MAX_KILOBYTES as the upper bound is indeed absolutely accurate, and
now everything is working correctly.

---
Best regards,
Daria Shanina

сб, 27 июн. 2026 г. в 05:50, Michael Paquier <michael@paquier.xyz>:

> On Fri, Jun 26, 2026 at 05:16:23PM +0900, Michael Paquier wrote:
> > 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.
>
> And just applied a patch doing so, HEAD-only.
> --
> Michael
>


-- 
С уважением,
Шанина Дарья Александровна