Re: Consistently use palloc_object() and palloc_array()
David Geier <geidav.pg@gmail.com>
From: David Geier <geidav.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-28T21:33:42Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
btree_gist: Fix memory allocation formula
- 5cf03552fbb4 19 (unreleased) landed
-
Use palloc_object() and palloc_array(), the last change
- 4f7dacc5b82a 19 (unreleased) landed
-
pg_buffercache: Fix memory allocation formula
- 580b5c2f397f 18.2 landed
- 3f83de20ba2e 19 (unreleased) landed
-
Fix allocation formula in llvmjit_expr.c
- 0c67dbcc4e39 14.21 landed
- 07ddf6197b78 15.16 landed
- 5a4dc4aabd03 16.12 landed
- 0bab0c3b74af 17.8 landed
- 5b7bbf16db34 18.2 landed
- 06761b6096b6 19 (unreleased) landed
-
Use palloc_object() and palloc_array() in backend code
- 1b105f9472bd 19 (unreleased) landed
-
Use palloc_object() and palloc_array() in more areas of the tree
- 0c3c5c3b06a3 19 (unreleased) landed
-
Use more palloc_object() and palloc_array() in contrib/
- 31d3847a37be 19 (unreleased) landed
Attachments
- verify_palloc_pairs.py (text/x-python)
Hi Michael! On 27.11.2025 01:24, Michael Paquier wrote: > On Wed, Nov 26, 2025 at 11:09:31PM +0100, David Geier wrote: >> I've changed all code to use the "new" palloc_object(), palloc_array(), >> palloc0_object(), palloc0_array, repalloc_array() and repalloc0_array() >> macros. This makes the code more readable and more consistent. >> >> The patch is pretty big but potential merge conflicts should be easy to >> resolve. If preferred, I can also further split up the patch, e.g. >> directory by directory or high impact files first. > > The backpatching extra-pain argument indeed comes into mind first when > it comes to such changes, but perhaps we should just bite the bullet > and encourage the new allocation styles across the tree, as you are > doing here. I'm not completely sure if it would make sense to split > things up, if we do I would do it on a subdirectory basis like to > suggest, perhaps, like contrib/, src/backend/executor/, etc. to > balance the blast damage. Did you use some kind of automation to find > all of these? If yes, what did you use? I thought again about splitting up the patch. I'm not sure how useful this really is. If a single committer takes this on, then it doesn't really matter. He can apply the patch but then commit directory by directory or in any other way he deems best. If we want to divide the work among multiple committers splitting might be more useful. Just tell me what you prefer and I'll provide the patch accordingly. >> The patch is passing "meson test" and I've additionally wrote a script >> that parses the patch file and verifies that every two corresponding + >> and - lines match (e.g. palloc0() replaced by palloc0_array() or >> palloc0_object(), the same for palloc() and repalloc(), additionally >> some checks to make sure the conversion to the _array() variant is >> correct). > > It may be an idea to share that as well, so as your checks could be > replicated rather than partially re-guessed. I've attached the script. You can run it via python3 verify_palloc_pairs.py patch_file Disclaimer: The script is a bit of a mess. It doesn't check repalloc() and it still reports five conversions as erroneous while they're actually correct. I checked them manually. I left it at that because the vast majority of changes it processes correctly and all tests pass. The repalloc() occurrences I also checked manually. -- David Geier