Horton

Re: Consistently use palloc_object() and palloc_array()

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: David Geier <geidav.pg@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Chao Li <li.evan.chao@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-12-03T00:35:52Z
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 Tue, Dec 02, 2025 at 04:13:01PM +0100, David Geier wrote:
> So reviewing this patch can now be done by only going through all files
> that have changes in the disassembly. This is only 54 out of which most
> are because of changes in the number of LOC or where the brackets are
> placed.

It may be a good idea to split the patch into two parts, at least:
- One for the bulk of the changes, for the straight-forward changes.
Most of what you are suggesting are that for palloc_object and
palloc_array which are dropped-in replacements.  Checking that these
assemble the same before and after offers one extra layer of
confidence.
- Second one for the more dubious changes.

It does not change that all these need to be looked with human eyes.
For the first one, splitting things based on the code area is simpler
With more than 1.7k places changed, splitting by area and checking
them individually would be the best course, at least for me when it
comes to such mechanical changes.  It comes down with dealing with
individual doses that are not so large that they cause one's head to
spin in the middle of checking the diffs (did that a few times in the
past for this code tree, splitting and dose balance helps a lot).

I cannot say for the others, but I find the type-safety argument
mentioned upthread good enough to do a switch and encourage more the
new style moving forward.
--
Michael