Re: Set huge_page_size on 32bit system

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

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(at)paquier(dot)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
>

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2026-06-30 15:58:08 Re: BUG #19540: Inconsistent integer-to-octal formatting for permission GUCs in pg_settings (boot_val vs setting)
Previous Message Dean Rasheed 2026-06-30 08:35:18 Re: BUG #19536: UPDATE RETURNING OLD value is stale after concurrent update when table has a BEFORE UPDATE trigger