Horton

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

  1. Avoid unnecessary StringInfo allocation in tablesync COPY buffer

    Chao Li <li.evan.chao@gmail.com> — 2026-05-09T06:10:50Z

    Hi,

I found this issue while reviewing the patch [1] and was suggested use a separate thread for the issue.

In tablesync.c, copy_table() currently does:
```
   copybuf = makeStringInfo();
```

But copybuf is only used by copy_read_data(), and there it's really just acting as a small state holder for data, len, and cursor, rather than as a normal growable StringInfo. That means we do not need to allocate a StringInfo object or its backing buffer at all.

It would be cleaner to use a plain StringInfoData and simply reinitialize or zero it in copy_table(). See the attached patch for the proposed change.

David Rowley has made several cleanup changes in this area to prefer stack-allocated StringInfoData, for example a63bbc811d41b3567eb37fe2636e660a852dbbf2. This change seems consistent with that direction.

[1] https://postgr.es/m/CAOzEurQKuy3RiPkd=25PEwEzaqHuGvEOf=X7vaVzhgNjaukYzA@mail.gmail.com

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  2. Re: Avoid unnecessary StringInfo allocation in tablesync COPY buffer

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-05-09T15:35:05Z

    Hello,

On 2026-May-09, Chao Li wrote:

> I found this issue while reviewing the patch [1] and was suggested use
> a separate thread for the issue.
> 
> In tablesync.c, copy_table() currently does:
> ```
>    copybuf = makeStringInfo();
> ```
> 
> But copybuf is only used by copy_read_data(), and there it's really
> just acting as a small state holder for data, len, and cursor, rather
> than as a normal growable StringInfo.

I find this coding pattern weird and ugly and confusing.  If what we
need is three variables, shouldn't we have three variables instead of
this strange misuse of the StringInfo abstraction?

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"We have labored long to build a heaven, only           (Prof. Milton Glass)
 to find it populated with horrors"                   (Watchmen, Alan Moore)

  3. Re: Avoid unnecessary StringInfo allocation in tablesync COPY buffer

    Chao Li <li.evan.chao@gmail.com> — 2026-05-11T07:09:21Z

    
> On May 9, 2026, at 23:35, Álvaro Herrera <alvherre@kurilemu.de> wrote:
> 
> Hello,
> 
> On 2026-May-09, Chao Li wrote:
> 
>> I found this issue while reviewing the patch [1] and was suggested use
>> a separate thread for the issue.
>> 
>> In tablesync.c, copy_table() currently does:
>> ```
>>   copybuf = makeStringInfo();
>> ```
>> 
>> But copybuf is only used by copy_read_data(), and there it's really
>> just acting as a small state holder for data, len, and cursor, rather
>> than as a normal growable StringInfo.
> 
> I find this coding pattern weird and ugly and confusing.  If what we
> need is three variables, shouldn't we have three variables instead of
> this strange misuse of the StringInfo abstraction?
> 

Yep, I first considered adding a file-local structure, but decided to keep the changes minimal in the first version.

In v2, I switched to using a small file-local CopyBuf structure.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/