Horton

Re: Consistently use palloc_object() and palloc_array()

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Thomas Munro <thomas.munro@gmail.com>, David Geier <geidav.pg@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-12-03T19:11:45Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. btree_gist: Fix memory allocation formula

  2. Use palloc_object() and palloc_array(), the last change

  3. pg_buffercache: Fix memory allocation formula

  4. Fix allocation formula in llvmjit_expr.c

  5. Use palloc_object() and palloc_array() in backend code

  6. Use palloc_object() and palloc_array() in more areas of the tree

  7. Use more palloc_object() and palloc_array() in contrib/

On 27.11.25 03:53, Thomas Munro wrote:
> 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.

On macOS ARM, I have MAXALIGN == alignof(max_align_t) == 8, but 
alignof(__int128) == 16.  (macOS Intel has 16/16.)  Also, as a 
consequence of that, the result of malloc() is not guaranteed to be 
aligned sufficiently for __int128 (need to use aligned_alloc()).  So it 
seems to me that the current behavior of palloc() is pretty consistent 
with that.