On Thu, Nov 27, 2025 at 11:10 AM David Geier <[email protected]> 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
