Message-ID: <accd2714-19ea-43a6-b4ea-29ae5416431c@gmail.com>
Date: Fri, 5 Dec 2025 13:53:37 +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: <ad0748d4-3080-436e-b0bc-ac8f86a3466a@gmail.com>
 <ED821EDD-6A1B-45B8-9005-31BCFFCB5A48@gmail.com>
 <a29b0cd9-576f-486f-ba45-5139ee33adcf@gmail.com>
 <524587.1764365323@sss.pgh.pa.us>
 <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>
Content-Language: en-US
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: <aTKMtSMTh4eiSGMr@paquier.xyz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/accd2714-19ea-43a6-b4ea-29ae5416431c%40gmail.com>
Precedence: bulk

On 05.12.2025 08:41, Michael Paquier wrote:
> 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.

My bad. I hadn't realized that - obviously - not necessarily all code is
actually compiled by default.

Will the build system enable any target for which all dependencies (e.g.
libraries) are met, or are there targets that need to be enabled
explicitly? Is there a way to enable all of them so I can easily make
sure, I actually compile all code?

> And done with the contrib/ part for the trival changes.

Thanks for applying the first batch of changes.

--
David Geier