| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | vilensipkdm(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Set huge_page_size on 32bit system |
| Date: | 2026-06-26 08:16:23 |
| Message-ID: | aj41V5ACiv9OfkIF@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2026-06-26 08:30:28 | Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table |
| Previous Message | Kyotaro Horiguchi | 2026-06-26 08:13:07 | Re: Set huge_page_size on 32bit system |