Re: Consistently use palloc_object() and palloc_array()

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