Re: Set huge_page_size on 32bit system

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: vilensipkdm(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Set huge_page_size on 32bit system
Date: 2026-06-26 04:24:15
Message-ID: 20260626.132415.904994526137946499.horikyota.ntt@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello,

At Thu, 25 Jun 2026 17:54:46 +0300, Daria Shanina <vilensipkdm(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro Horiguchi 2026-06-26 04:57:41 Re: uuidv7 improperly accepts dates before 1970-01-01
Previous Message Jacob Champion 2026-06-26 00:12:42 Re: REVOKE's CASCADE protection doesn't work with INHERITed table owners