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: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Chao Li <li.evan.chao@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-12-10T23:01:49Z
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, Dec 10, 2025 at 12:48:35PM +0100, David Geier wrote:
> On 09.12.2025 23:37, Michael Paquier wrote:
>> On Fri, Dec 05, 2025 at 04:41:41PM +0900, Michael Paquier wrote:
> Do you mean in these files I forgot removing casts that got unnecessary
> after using _array() / _object()? It's possible that I missed some,
> given the large amount. Please fix them as you see fit.

Yes, your patch did not remove casts in all the files I have listed
upthread.  I have fixed them already in the tree, for all the trivial
changes.

>> One can argue that this one in bernouilli.c is not really necessary,
>> tsm_state is actually a void *.
> 
> As stated above: this change is not only about saving casts but the
> macros convey the intent much better than a call to palloc().

I got that, but I could not convinced myself that such cases are worth
it.  We don't have many of them in the tree anyway.  They count for
less than 1% of all the changes dealt with here 

>> Among the 300-ish files changed in the backend, 48 of them had their
>> builds slightly change.  The list of them is attached.
> 
> Do you mean the disassembly because the number of lines of code changes?

Yes, I have cross-checked the reports generated between before and
after the patches, to see that they matched with the formulas
changing.  A trick that I have used here and that was rather painful
is to manually change the files where the formulas got shorter to make
their build match..  But well..

I still need to get through the remaining dubious changes you have
posted, including the llvm one that was wrong.  It seems like some of
these things warrant a backpatch.
--
Michael