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