Re: pgbench: make verbose error messages thread-safe - Mailing list pgsql-hackers

From Chao Li
Subject Re: pgbench: make verbose error messages thread-safe
Date
Msg-id 8BFDCED2-C691-45C0-A30F-574DEFED1F6D@gmail.com
Whole thread
In response to Re: pgbench: make verbose error messages thread-safe  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pgbench: make verbose error messages thread-safe
List pgsql-hackers

> On Apr 24, 2026, at 16:07, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Apr 24, 2026 at 03:26:03PM +0900, Fujii Masao wrote:
>> Attached patch fixes this issue by changing printVerboseErrorMessages()
>> to use a local PQExpBufferData instead of a static one. Thoughts?
>
> That looks like an oversight of 4a39f87acd6e to me.  A static buffer
> in this context is not adapted.
>
>> Since this issue was introduced in v15, the patch should be
>> backpatched to v15 if accepted.
>
> This forces a new allocation for each message printed vs a set of
> resets after one allocation is done.  This change is not going to be
> entirely free as done in the patch, so should we worry about that?
> Perhaps it would be cheaper to allocate a PQExpBuffer in each CState,
> and just reuse it in this routine?
> --
> Michael

I am not too worried about that, because this code path is only used with --verbose-errors and only when printing error
messages.In that situation, the cost of one extra memory allocation per log line should be much smaller than the I/O
costof writing the log message itself. So I think the simpler fix is probably acceptable. 

But if we really care about the performance problem, I think PQExpBuffer might be better stored in TState that is per
thread,while CState is per connection. 

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







pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Use-after-free issue in postgres_fdw
Next
From: Alberto Piai
Date:
Subject: Re: Adding a stored generated column without long-lived locks