From: David Geier <geidav.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Consistently use palloc_object() and palloc_array()
Date: Fri, 5 Dec 2025 13:53:37 +0100
Message-ID: <accd2714-19ea-43a6-b4ea-29ae5416431c@gmail.com> (raw)
In-Reply-To: <aTKMtSMTh4eiSGMr@paquier.xyz>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: geidav.pg@gmail.com, michael@paquier.xyz, tgl@sss.pgh.pa.us, thomas.munro@gmail.com, li.evan.chao@gmail.com
Subject: Re: Consistently use palloc_object() and palloc_array()
In-Reply-To: <accd2714-19ea-43a6-b4ea-29ae5416431c@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox