Hi Thomas! On 27.11.2025 03:53, Thomas Munro wrote: > 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
These are some interesting ideas but I would consider them for now as possible follow-up work, once this refactoring is merged. -- David Geier
