| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pgbench: make verbose error messages thread-safe |
| Date: | 2026-04-24 09:05:28 |
| Message-ID: | 8BFDCED2-C691-45C0-A30F-574DEFED1F6D@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Apr 24, 2026, at 16:07, Michael Paquier <michael(at)paquier(dot)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 cost of 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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alberto Piai | 2026-04-24 09:10:22 | Re: Adding a stored generated column without long-lived locks |
| Previous Message | Etsuro Fujita | 2026-04-24 08:59:22 | Re: Use-after-free issue in postgres_fdw |