Use stack allocated StringInfoDatas, where possible (round 2)
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: pgsql-hackers@lists.postgresql.org
Cc: David Rowley <dgrowleyml@gmail.com>
Date: 2026-04-12T10:49:38Z
Lists: pgsql-hackers
Attachments
Hi hackers, Commit 6d0eba66275 already did most of the changes but missed the opportunities to $SUBJECT in sequencesync.c. Indeed, 5509055d6956 added a few cases that are using StringInfo but don't need that StringInfo to exist beyond the scope of the function were using makeStringInfo(), which allocates both a StringInfoData and the buffer it uses as two separate allocations. It's more efficient for these cases to use a StringInfoData on the stack and initialize it with initStringInfo(), which only allocates the string buffer. The reason 6d0eba66275 missed those is that 5509055d6956 has been committed between the patch proposal for 6d0eba66275 and 6d0eba66275. I used Mats's coccinelle script (mentioned in [1]) to find those and they are the only remaining ones. [1]: https://postgr.es/m/4379aac8-26f1-42f2-a356-ff0e886228d3%40gmail.com Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Use stack-allocated StringInfoDatas, where possible
- a63bbc811d41 19 (unreleased) landed
-
Use stack allocated StringInfoDatas, where possible
- 6d0eba66275b 19 (unreleased) cited