Horton

Re: Consistently use palloc_object() and palloc_array()

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: David Geier <geidav.pg@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-27T03:25:12Z
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/

Thomas Munro <thomas.munro@gmail.com> writes:
> 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.

Hmm ... I had the same doubts as Michael about whether this change
could possibly be worth the ensuing back-patching pain.  But if
it leads to an improvement in type-safety, that'd be a reason to
take on the work.

			regards, tom lane