Re: Consistently use palloc_object() and palloc_array()

Michael Paquier <michael@paquier.xyz>

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-05T07:41:41Z

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 →

btree_gist: Fix memory allocation formula
- 5cf03552fbb4 19 (unreleased) landed
Use palloc_object() and palloc_array(), the last change
- 4f7dacc5b82a 19 (unreleased) landed
pg_buffercache: Fix memory allocation formula
- 580b5c2f397f 18.2 landed
- 3f83de20ba2e 19 (unreleased) landed
Fix allocation formula in llvmjit_expr.c
- 0c67dbcc4e39 14.21 landed
- 07ddf6197b78 15.16 landed
- 5a4dc4aabd03 16.12 landed
- 0bab0c3b74af 17.8 landed
- 5b7bbf16db34 18.2 landed
- 06761b6096b6 19 (unreleased) landed
Use palloc_object() and palloc_array() in backend code
- 1b105f9472bd 19 (unreleased) landed
Use palloc_object() and palloc_array() in more areas of the tree
- 0c3c5c3b06a3 19 (unreleased) landed
Use more palloc_object() and palloc_array() in contrib/
- 31d3847a37be 19 (unreleased) landed

On Thu, Dec 04, 2025 at 10:31:41AM +0100, David Geier wrote:
> Attached are the two patches, rebased on latest master.
> 
> The first one contains all changes that either result in no changes to
> the disassembly, or only in changes due to the line counts; because
> elog.h makes use of __LINE__.

Thanks.  That's a lot to digest.

I have generated some reports by comparing builds of HEAD and
HEAD+0001 to indeed note that a lot of noise is caused by the line
number changes.  And then, I have begun looking at contrib/ to start
with something as I had a bit of time today.  One part which we need
to be careful about is that the allocations map with the actual
declarations, and I'm doubting my compiler to detect all of them, so
visual check for each path it is...

-   void       *out = palloc(sizeof(float4KEY));
+   void       *out = palloc_object(float4KEY);

btree_gist/ has a bunch of these, which I guess don't really matter in
terms of type safety.

-   sv = palloc(sizeof(bytea *) * (maxoff + 1));
+   sv = palloc_array(bytea *, (maxoff + 1));

This one also in gbt_var_picksplit@btree_utils_var.c.  We have a
GBT_VARKEY.

+   keys = (char **) palloc_array(char *, key_count);
+   values = (char **) palloc_array(char *, val_count);

These two should not need casts.

-               stack = palloc(sizeof(*stack));
+               stack = palloc_object(sepgsql_proc_stack);

This one in sepgsql was wrong, that can be detected with a compilation
of the module.

And done with the contrib/ part for the trival changes.
--
Michael