From: David Geier <geidav.pg@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
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: Tue, 2 Dec 2025 16:13:01 +0100
Message-ID: <143d3184-b575-49bd-8bc1-f37f45f010cc@gmail.com> (raw)
In-Reply-To: <CA+hUKGL+hiMRrAOqop1wmfpqTLg3GdyAJmO6KH6Dz3FjQvGN+w@mail.gmail.com>
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>
On 28.11.2025 23:31, Thomas Munro wrote:
> On Sat, Nov 29, 2025 at 10:47 AM David Geier <geidav.pg@gmail.com> wrote:
>> I intentionally tried to avoid any semantic changes but it's of course
>> possible something slipped through by accident.
>
> Do you expect the generated code to be identical? Is it?
In the majority of cases yes. However, there are a few cases where a
small change in the C code can yield to differences in the generated code:
I used the following bash script to create the disassembly of all object
files in the build directory. I ran this script twice, once on master
and once on the patched branch. The directory needs to be adapted
accordingly in the script.
find . -name "*.o" -print0 | while IFS= read -r -d '' file; do
mkdir -p ~/Desktop/master/"$(dirname "$file")"
if objdump -drwC -Mintel "$file" > ~/Desktop/master/"$file".dis
2>/dev/null; then
echo " ✓ Disassembled to ~/Desktop/master/$file.dis"
else
echo " ✗ Failed to disassemble $file"
fi
done
There are 54 files that show changes in the generated code. I didn't
look through all files but the changes are largely caused by the same
reasons:
1) If the refactoring introduces a change in the number of lines, the
__LINE__ macro used by elog.h will cause a change in the disassembly.
This is the reason for the majority of changes.
2) fuzzystrmatch.c: contains a functional change. We allocate 1 byte
more now but that is safe, see [1].
3) pg_buffercache_pages.c: Functional change. Type used in
palloc_array() changed from uint64 to int, as the rest of the code only
uses an integer.
4) trgm_op.c: Contains arithmetic expressions in the calls to
palloc_array() where now the brackets are placed differently, e.g.
sizeof(type) * a * b vs sizeof(type) * (a * b). That's the reason for
many differences.
So reviewing this patch can now be done by only going through all files
that have changes in the disassembly. This is only 54 out of which most
are because of changes in the number of LOC or where the brackets are
placed.
[1] https://www.postgresql.org/message-id/524587.1764365323%40sss.pgh.pa.us
--
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, thomas.munro@gmail.com, tgl@sss.pgh.pa.us, li.evan.chao@gmail.com
Subject: Re: Consistently use palloc_object() and palloc_array()
In-Reply-To: <143d3184-b575-49bd-8bc1-f37f45f010cc@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