Re: Consistently use palloc_object() and palloc_array()

Hi Thomas!

On 27.11.2025 03:53, Thomas Munro wrote:
> On Thu, Nov 27, 2025 at 11:10 AM David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:
>> I've changed all code to use the "new" palloc_object(), palloc_array(),
>> palloc0_object(), palloc0_array, repalloc_array() and repalloc0_array()
>> macros. This makes the code more readable and more consistent.
>
> 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.
>
> This isn't a fully-baked thought, just a thought that occurred to me
> while looking into that: If palloc_object(Int128AggState) were smart
> enough to detect that alignof(T) > MAXALIGN and redirect to
> palloc_aligned(sizeof(T), alignof(T), ...) at compile time, then
> Int128AggState would naturally propagate the layout requirements of
> its __int128 member, and we wouldn't need to do that weird stuff, and
> it wouldn't be error-prone if usage of __int128 spreads to more
> structs. That really only makes sense if we generalise
> palloc_object() as a programming style and consider direct use of
> palloc() to be a rarer low-level interface that triggers human
> reviewers to think about alignment, I guess. I think you'd also want
> a variant that can deal with structs ending in a flexible array
> member, but that seems doable... palloc_flexible_object(T,
> flexible_member, flexible_elements) or whatever. But I might also be
> missing some parts of that puzzle, for example it wouldn't make sense
> if __int128 is ever stored.
>
> [1] https://www.postgresql.org/message-id/CA%2BhUKGLQUivg-NC7dHdbRAPmG0Hapg1gGnygM5KgDfDM2a_TMg%40mail.gmail.com

These are some interesting ideas but I would consider them for now as
possible follow-up work, once this refactoring is merged.

--
David Geier