public inbox for [email protected]
help / color / mirror / Atom feedSet huge_page_size on 32bit system
7+ messages / 3 participants
[nested] [flat]
* Set huge_page_size on 32bit system
@ 2026-06-25 14:54 Daria Shanina <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Daria Shanina @ 2026-06-25 14:54 UTC (permalink / raw)
To: [email protected]
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
Starting program: /home/vboxuser/projects/psql/bugfix_pgpro7219/master/build/bin/postgres
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Program received signal SIGFPE, Arithmetic exception.
0x0096ef81 in CreateAnonymousSegment (size=0xbfffeef0) at pg_shmem.c:621
621 if (allocsize % hugepagesize != 0)
#0 0x0096ef81 in CreateAnonymousSegment (size=0xbfffeef0) at pg_shmem.c:621
hugepagesize = 0
huge_mmap_flags = 262144
allocsize = 154329088
ptr = 0xffffffff
mmap_errno = 0
mmap_flags = 33
__func__ = "CreateAnonymousSegment"
#1 0x0096f2ff in PGSharedMemoryCreate (size=154329088, shim=0xbfffef04) at pg_shmem.c:741
NextShmemSegID = 10759567
memAddress = 0x932d738
hdr = 0xc78b6e <errstart+169>
statbuf = {st_dev = 2049, __pad1 = 0, __st_ino = 0, st_mode = 16832, st_nlink = 19, st_uid = 1000, st_gid = 1000, st_rdev = 0, __pad2 = 0, st_size = 4096, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1782287996, tv_nsec = 729867291}, st_mtim = {tv_sec = 1782288163, tv_nsec = 798191630}, st_ctim = {tv_sec = 1782288163, tv_nsec = 798191630}, st_ino = 1189604}
sysvsize = 61176
__func__ = "PGSharedMemoryCreate"
#2 0x00a42e78 in CreateSharedMemoryAndSemaphores () at ipci.c:135
shim = 0x94
seghdr = 0x932e000
size = 154329088
__func__ = "CreateSharedMemoryAndSemaphores"
#3 0x0097f34a in PostmasterMain (argc=1, argv=0x1134ba0) at postmaster.c:1018
optctx = {nargc = 1, nargv = 0x1134ba0, ostr = 0xe93138 "B:bC:c:D:d:EeFf:h:ijk:lN:OPp:r:S:sTt:W:-:", opterr = 1, optarg = 0x0, optind = 1, optopt = 0, place = 0xf976bc ""}
opt = -1
status = 8596279
userDoption = 0x0
listen_addr_saved = false
output_config_variable = 0x0
__func__ = "PostmasterMain"
#4 0x008324b6 in main (argc=1, argv=0x1134ba0) at main.c:231
do_check_root = true
dispatch_option = DISPATCH_POSTMASTER
Attachments:
[text/plain] gdb.txt (2.0K, ../../CAMp4U1d177Jf9ZJwXGKom6APx3LSFATa=Z-M=N5kLzvTUcxutw@mail.gmail.com/3-gdb.txt)
download | inline:
Starting program: /home/vboxuser/projects/psql/bugfix_pgpro7219/master/build/bin/postgres
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Program received signal SIGFPE, Arithmetic exception.
0x0096ef81 in CreateAnonymousSegment (size=0xbfffeef0) at pg_shmem.c:621
621 if (allocsize % hugepagesize != 0)
#0 0x0096ef81 in CreateAnonymousSegment (size=0xbfffeef0) at pg_shmem.c:621
hugepagesize = 0
huge_mmap_flags = 262144
allocsize = 154329088
ptr = 0xffffffff
mmap_errno = 0
mmap_flags = 33
__func__ = "CreateAnonymousSegment"
#1 0x0096f2ff in PGSharedMemoryCreate (size=154329088, shim=0xbfffef04) at pg_shmem.c:741
NextShmemSegID = 10759567
memAddress = 0x932d738
hdr = 0xc78b6e <errstart+169>
statbuf = {st_dev = 2049, __pad1 = 0, __st_ino = 0, st_mode = 16832, st_nlink = 19, st_uid = 1000, st_gid = 1000, st_rdev = 0, __pad2 = 0, st_size = 4096, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1782287996, tv_nsec = 729867291}, st_mtim = {tv_sec = 1782288163, tv_nsec = 798191630}, st_ctim = {tv_sec = 1782288163, tv_nsec = 798191630}, st_ino = 1189604}
sysvsize = 61176
__func__ = "PGSharedMemoryCreate"
#2 0x00a42e78 in CreateSharedMemoryAndSemaphores () at ipci.c:135
shim = 0x94
seghdr = 0x932e000
size = 154329088
__func__ = "CreateSharedMemoryAndSemaphores"
#3 0x0097f34a in PostmasterMain (argc=1, argv=0x1134ba0) at postmaster.c:1018
optctx = {nargc = 1, nargv = 0x1134ba0, ostr = 0xe93138 "B:bC:c:D:d:EeFf:h:ijk:lN:OPp:r:S:sTt:W:-:", opterr = 1, optarg = 0x0, optind = 1, optopt = 0, place = 0xf976bc ""}
opt = -1
status = 8596279
userDoption = 0x0
listen_addr_saved = false
output_config_variable = 0x0
__func__ = "PostmasterMain"
#4 0x008324b6 in main (argc=1, argv=0x1134ba0) at main.c:231
do_check_root = true
dispatch_option = DISPATCH_POSTMASTER
[text/x-patch] fix-for-huge_page_size.patch (731B, ../../CAMp4U1d177Jf9ZJwXGKom6APx3LSFATa=Z-M=N5kLzvTUcxutw@mail.gmail.com/4-fix-for-huge_page_size.patch)
download | inline diff:
diff --git a/src/backend/port/sysv_shmem.c b/src/backend/port/sysv_shmem.c
index 2e3886cf9fe..8bb31698bd0 100644
--- a/src/backend/port/sysv_shmem.c
+++ b/src/backend/port/sysv_shmem.c
@@ -618,6 +618,13 @@ CreateAnonymousSegment(Size *size)
GetHugePageSize(&hugepagesize, &huge_mmap_flags);
+ if (hugepagesize == 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_OUT_OF_MEMORY),
+ errmsg("Cannot alocate %d bytes of memory", hugepagesize),
+ errhint("It is necessary to reduce the amount of the configuration parameter \'huge_page_size\' (currently huge_page_size %d kB)",
+ huge_page_size)));
+
if (allocsize % hugepagesize != 0)
allocsize = add_size(allocsize, hugepagesize - (allocsize % hugepagesize));
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Set huge_page_size on 32bit system
@ 2026-06-26 04:24 Kyotaro Horiguchi <[email protected]>
parent: Daria Shanina <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Kyotaro Horiguchi @ 2026-06-26 04:24 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
Hello,
At Thu, 25 Jun 2026 17:54:46 +0300, Daria Shanina <[email protected]> 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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Set huge_page_size on 32bit system
@ 2026-06-26 05:26 Michael Paquier <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Michael Paquier @ 2026-06-26 05:26 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]
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
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Set huge_page_size on 32bit system
@ 2026-06-26 08:13 Kyotaro Horiguchi <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Kyotaro Horiguchi @ 2026-06-26 08:13 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]
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.
Regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Set huge_page_size on 32bit system
@ 2026-06-26 08:16 Michael Paquier <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Michael Paquier @ 2026-06-26 08:16 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Set huge_page_size on 32bit system
@ 2026-06-27 02:50 Michael Paquier <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Michael Paquier @ 2026-06-27 02:50 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]
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
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Set huge_page_size on 32bit system
@ 2026-06-30 13:23 Daria Shanina <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Daria Shanina @ 2026-06-30 13:23 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; [email protected]
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 <[email protected]>:
> 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
>
--
С уважением,
Шанина Дарья Александровна
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-06-30 13:23 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-25 14:54 Set huge_page_size on 32bit system Daria Shanina <[email protected]>
2026-06-26 04:24 ` Kyotaro Horiguchi <[email protected]>
2026-06-26 05:26 ` Michael Paquier <[email protected]>
2026-06-26 08:13 ` Kyotaro Horiguchi <[email protected]>
2026-06-26 08:16 ` Michael Paquier <[email protected]>
2026-06-27 02:50 ` Michael Paquier <[email protected]>
2026-06-30 13:23 ` Daria Shanina <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox