Re: Use stack allocated StringInfoDatas, where possible (round 2)
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2026-04-12T13:34:52Z
Lists: pgsql-hackers
On Sun, 12 Apr 2026 at 22:49, Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote: > 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. I think the author of copy_sequences() doesn't know what resetStringInfo() does. I expect they think that it'll pfree all the memory, but that's what destroyStringInfo() is for. Since the strings are not used after the resetStringInfo(), the call is pointless. Could you ask Amit K to fix that first? Then rebase your patch atop. I think it makes sense to apply your patch as a StringInfo fixup post-freeze for v19 as leaving this for v20 will just result in the code not matching for no particularly good reason. David
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