| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, David Geier <geidav(dot)pg(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Consistently use palloc_object() and palloc_array() |
| Date: | 2025-12-03 19:11:45 |
| Message-ID: | b480c84a-cfe3-453c-b882-ed45518d90f2@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27.11.25 03:53, Thomas Munro wrote:
> I wondered about this in the context of special alignment
> requirements[1]. palloc() aligns to MAXALIGN, which we artificially
> constrain for various reasons that we can't easily change (at least
> not without splitting on-disk MAXALIGN from allocation MAXALIGN, and
> if we do that we'll waste more memory). That's less than
> alignof(max_align_t) on common systems, so then we have to do some
> weird stuff to handle __int128 that doesn't fit too well into modern
> <stdalign.h> thinking and also disables optimal codegen.
On macOS ARM, I have MAXALIGN == alignof(max_align_t) == 8, but
alignof(__int128) == 16. (macOS Intel has 16/16.) Also, as a
consequence of that, the result of malloc() is not guaranteed to be
aligned sufficiently for __int128 (need to use aligned_alloc()). So it
seems to me that the current behavior of palloc() is pretty consistent
with that.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2025-12-03 19:12:40 | Re: POC: make mxidoff 64 bits |
| Previous Message | Heikki Linnakangas | 2025-12-03 19:07:14 | Tighten up range checks for pg_resetwal arguments |