Thread

  1. Re: Consistently use palloc_object() and palloc_array()

    Thomas Munro <thomas.munro@gmail.com> — 2025-11-27T02:53:20Z

    On Thu, Nov 27, 2025 at 11:10 AM David Geier <geidav.pg@gmail.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