Re: Suggestion to add --continue-client-on-abort option to pgbench - Mailing list pgsql-hackers
| From | Yugo Nagata |
|---|---|
| Subject | Re: Suggestion to add --continue-client-on-abort option to pgbench |
| Date | |
| Msg-id | 20250716224957.d7d0ee239a70640d2d154f53@sraoss.co.jp Whole thread Raw |
| In response to | Re: Suggestion to add --continue-client-on-abort option to pgbench (Rintaro Ikeda <ikedarintarof@oss.nttdata.com>) |
| Responses |
Re: Suggestion to add --continue-client-on-abort option to pgbench
|
| List | pgsql-hackers |
On Wed, 16 Jul 2025 21:35:01 +0900
Rintaro Ikeda <ikedarintarof@oss.nttdata.com> wrote:
> Hi,
>
> On 2025/07/15 11:16, Yugo Nagata wrote:
> >> I noticed one small thing I’d like to discuss. I'm not sure that users clearly
> >> understand which aborted in the following error message, the client or the script.
> >>> pgbench: error: client 0 script 0 aborted in command ... query ...
> >>
> >> Since the code path always results in a client abort, I wonder if the following
> >> message might be clearer:
> >>> pgbench: error: client 0 aborted in script 0 command ... query ...
> >
> > Indeed, it seems clearer to explicitly state that it is the client that
> > was aborted.
> >
> > I've attached an updated patch that replaces the remaining message mentioned
> > above with a call to commandFailed(). With this change, the output in such
> > situations will now be:
> >
> > "client 0 aborted in command 0 (SQL) of script 0; ...."
>
> Thank you for updating the patch!
>
> When I executed a custom script that may raise a unique constraint violation, I
> got the following output:
> > pgbench: error: client 0 script 0 aborted in command 1 query 0: ERROR:
> duplicate key value violates unique constraint "test_col2_key"
I'm sorry. I must have failed to attach the correct patch in my previous post.
As a result, patch v8 was actually the same as v7, and the message in question
was not modified as intended.
>
> I think we should also change the error message in pg_log_error. I modified the
> patch v8-0003 as follows:
> @@ -3383,8 +3383,8 @@ readCommandResponse(CState *st, MetaCommand meta, char
> *varprefix)
>
> default:
> /* anything else is unexpected */
> - pg_log_error("client %d script %d aborted in
> command %d query %d: %s",
> - st->id, st->use_file,
> st->command, qrynum,
> + pg_log_error("client %d aborted in command %d
> query %d of script %d: %s",
> + st->id, st->command,
> qrynum, st->use_file,
> PQerrorMessage(st->con));
> goto error;
> }
>
> With this change, the output now is like this:
> > pgbench: error: client 0 aborted in command 1 query 0 of script 0: ERROR:
> duplicate key value violates unique constraint "test_col2_key"
>
> I want hear your thoughts.
My idea is to modify this as follows;
default:
/* anything else is unexpected */
- pg_log_error("client %d script %d aborted in command %d query %d: %s",
- st->id, st->use_file, st->command, qrynum,
- PQerrorMessage(st->con));
+ commandFailed(st, "SQL", PQerrorMessage(st->con));
goto error;
}
This fix is originally planned to be included in patch v8, but was missed.
It is now included in the attached patch, v10.
With this change, the output becomes:
pgbench: error: client 0 aborted in command 0 (SQL) of script 0;
ERROR: duplicate key value violates unique constraint "t2_pkey"
Although there is a slight difference, the message is essentially the same as
your proposal. Also, I believe the use of commandFailed() makes the code simpler
and more consistent.
What do you think?
> Also, let me ask one question. In this case, I directly modified your commit in
> the v8-0003 patch. Is that the right way to update the patch?
I’m not sure if that’s the best way, but I think modifying the patch directly is a
valid way to propose an alternative approach during discussion, as long as the original
patch is respected. It can often help clarify suggestions.
Regards,
Yugo Nagata
--
Yugo Nagata <nagata@sraoss.co.jp>
Attachment
pgsql-hackers by date: