Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use stack-allocated StringInfoDatas, where possible

  2. Use stack allocated StringInfoDatas, where possible

  1. Use stack allocated StringInfoDatas, where possible (round 2)

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-04-12T10:49:38Z

    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

  2. Re: Use stack allocated StringInfoDatas, where possible (round 2)

    David Rowley <dgrowleyml@gmail.com> — 2026-04-12T13:34:52Z

    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

  3. Re: Use stack allocated StringInfoDatas, where possible (round 2)

    David Rowley <dgrowleyml@gmail.com> — 2026-04-12T22:45:37Z

    On Mon, 13 Apr 2026 at 01:34, David Rowley <dgrowleyml@gmail.com> wrote:
> 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.

That was poor analysis. The resetStringInfo is there to reset the
StringInfo before the next loop. So nothing is wrong with it.

I've now pushed your patch.

David