Horton

Re: Consistently use palloc_object() and palloc_array()

David Geier <geidav.pg@gmail.com>

View thread
From: David Geier <geidav.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
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-10T11:48:35Z
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/

Hi Michael!

Thanks for continuing applying the patches.

On 09.12.2025 23:37, Michael Paquier wrote:
> On Fri, Dec 05, 2025 at 04:41:41PM +0900, Michael Paquier wrote:
>> Thanks.  That's a lot to digest.
> 
> Digesting a bit more now..
> 
> -   char       *ret = palloc(sizeof(buf));
> +   char       *ret = palloc_array(char, sizeof(buf))
> 
> This one in dumputils.c is right, but I am not sure that it is an
> improvement compared to the statu-quo.

Apart from saving casts, using the _array() and _object() variants
improves readability as it's clear from the used macro what the code
intents to do.

For example. without knowing the type of buf, it's not immediately clear
if this is allocating an array of the size of buf, or if it's allocating
an object (e.g. if buf happened to be some struct that represents a
buffer object).

The amount of allocated memory would of course be the same, but how it's
going to be used can be nicely derived from the used macro.

> Here is a list of the files where I have noticed tha addition of
> casts, which are not required anymore:
> brin_tuple.c.
> gistbuildbuffers.c.
> genam.c.
> nbtdedup.c.
> nbtree.c.
> nbtsort.c.
> index.c
> execGrouping.c
> execMain.c
> relnode.c
> partbounds.c
> mcv.c
> spell.c
> arrayfuncs.c
> partcache.c
> 
> Perhaps you have used a semi-automatic process and missed these?

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.

> 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().

> 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?

--
David Geier