Re: Consistently use palloc_object() and palloc_array() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Consistently use palloc_object() and palloc_array()
Date
Msg-id aTpXvSiis8ufin_I@paquier.xyz
Whole thread Raw
In response to Re: Consistently use palloc_object() and palloc_array()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Consistently use palloc_object() and palloc_array()
List pgsql-hackers
On Thu, Dec 11, 2025 at 08:01:49AM +0900, Michael Paquier wrote:
> 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.

I have been looking at the rest of these changes with some -O2, and I
have been puzzled by the differences in hstore_gin.c and hstore_op.c.
In all these cases we generate more instructions with the patch than
without the patch.  Anyway, I assume that these are the ones that
matter:
entries = (Datum *) palloc(sizeof(Datum) * 2 * count);
out_datums = palloc_array(Datum, count * 2);

pg_trgm.c was less puzzling.  For example:
-   trg1 = (trgm *) palloc(sizeof(trgm) * (slen1 / 2 + 1) * 3);
+   trg1 = palloc_array(trgm, (slen1 / 2 + 1) * 3);
This one leads to something like that before vs after:
<     1418:     83 c0 01                add    eax,0x1
>     1418:     8d 44 40 03             lea    eax,[rax+rax*2+0x3]

In execPartition.c and partprune.c, as far as I can see we are cutting
a few mov, leading to less instructions overall.

For mvdistinct.c, we are cutting things overall.  I am seeing less.

All the fuzz in postgres_fdw.c is caused by this one:
-   p_values = (const char **) palloc(sizeof(char *) * fmstate->p_nums
* numSlots);
+   p_values = palloc_array(const char *, fmstate->p_nums * numSlots);

bufmgr.c did not matter, same before and after.

I am not completely sure about the one in fuzzystrmatch, I would need
to study more the metaphone code.  :)

One formula in llvmjit_expr.c has been wrong since v10, so I have
backpatched a fix for it.

In pg_buffercache_pages.c, the difference is here:
-           os_page_status = palloc(sizeof(uint64) * os_page_count);
+           os_page_status = palloc_array(int, os_page_count);
Your formula is correct, the previous one was not by using a uint64.
So it allocated twice too much memory.  Backpatched this one down to
v18.

And that should close this thread, at least from my side..
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance
Next
From: Pavel Stehule
Date:
Subject: Re: Add a greedy join search algorithm to handle large join problems