Message-ID: <aa1df110-3559-49c6-8025-b51c593365e7@gmail.com>
Date: Thu, 11 Dec 2025 09:06:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Consistently use palloc_object() and palloc_array()
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>
References: <1e7f0c17-a965-4d5b-ad88-b435a4d97490@gmail.com>
 <CA+hUKGL+hiMRrAOqop1wmfpqTLg3GdyAJmO6KH6Dz3FjQvGN+w@mail.gmail.com>
 <143d3184-b575-49bd-8bc1-f37f45f010cc@gmail.com>
 <aS-F6LkeDBEly9nz@paquier.xyz> <534126.1764722446@sss.pgh.pa.us>
 <4ab4a12b-49e9-4ebf-9055-225c8055fed0@gmail.com>
 <aTKMtSMTh4eiSGMr@paquier.xyz> <aTikrhT9NvtKncUK@paquier.xyz>
 <adef550d-e776-4a91-be24-df7ca67fc3c1@gmail.com>
 <aTn73SDlm922r67G@paquier.xyz> <aTpXvSiis8ufin_I@paquier.xyz>
Content-Language: en-US
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: <aTpXvSiis8ufin_I@paquier.xyz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/aa1df110-3559-49c6-8025-b51c593365e7%40gmail.com>
Precedence: bulk

On 11.12.2025 06:33, Michael Paquier wrote:
> 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);

Yeah, in a few cases the different bracketing has some surprisingly big
influence on the generated assmebly.

> 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.  :)
Actually, the change in fuzzystrmatch.c is incorrect.

With the new code, palloc(0) will be called for strlen(word) == 0. Then
no space for the null-terminator byte will be left.

Even if palloc(0) returns memory that can be dereferenced, I don't think
it's a good idea to rely on that.

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

Thanks Michael for taking care of this patch!

--
David Geier