Horton

Re: Consistently use palloc_object() and palloc_array()

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, David Geier <geidav.pg@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-27T05:18:29Z
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 Wed, Nov 26, 2025 at 10:25:12PM -0500, Tom Lane wrote:
> 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.

Yeah, that sounds like a reason convincing enough to do the jump.  I
didn't really feel strongly against the original proposal to begin
with as it improves the code style, FWIW.

The backpatching bits like these are always annoying, of course.  Now,
these fancy palloc() routines exist since v16 so that would just mean
two years and two branches that would need special handling.  Even
better, why not just backpatch into v15 and v14 the macros in palloc.h
and fe_memutils.h to avoid backpatch hazards due to some new code?
--
Michael