public inbox for [email protected]  

help / color / mirror / Atom feed

From: Álvaro Herrera <[email protected]>
To: Chao Li <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Fujii Masao <[email protected]>
Subject: Re: Avoid unnecessary StringInfo allocation in tablesync COPY buffer
Date: Sat, 9 May 2026 17:35:05 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

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)

view thread (3+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Avoid unnecessary StringInfo allocation in tablesync COPY buffer
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox