Re: Suggestion to add --continue-client-on-abort option to pgbench

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Rintaro Ikeda <ikedarintarof(at)oss(dot)nttdata(dot)com>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "slpmcf(at)gmail(dot)com" <slpmcf(at)gmail(dot)com>, "boekewurm+postgres(at)gmail(dot)com" <boekewurm+postgres(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Suggestion to add --continue-client-on-abort option to pgbench
Date: 2025-11-13 09:40:36
Message-ID: 20251113184036.156e63394623d116840fe73c@sraoss.co.jp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 13 Nov 2025 16:13:30 +0800
Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:

> Now, all transactions are processed, there is no failure, I think that is expected, because syncpipeline should rollback failures, so that all script should succeed.
>
> Feels to me like, because of introducing the new discardAvailableResults(), we need to make different fixes for master and old branches.

I understand your claim that scripts rolled back by \syncpipeline should
be considered successful. However, I believe treating them as failed
transactions is the expected behavior in pgbench, since it assumes that
a transaction script contains only one transaction, as described in the
documentation [1].

The following script:

\startpipeline
<queries list 1>
\syncpipeline
<queries list 2>
\endpipeline

can be considered equivalent to:

BEGIN;
<queries list 1>
END;
BEGIN;
<queries list 2>
END;

with respect to the scope of queries rolled back.
In the latter script, an error (such as a deadlock or serialization failure)
in any query is recorded as a failed transaction in the current pgbench, even
if part of the script has already been committed.
Therefore, the same behavior would be expected for the former script using a
pipeline.

[1] https://www.postgresql.org/docs/current/pgbench.html#FAILURES-AND-RETRIES

Regards,
Yugo Nagata

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2025-11-13 09:52:29 Re: Rename sync_error_count to tbl_sync_error_count in subscription statistics
Previous Message John Naylor 2025-11-13 09:38:04 Re: [PATCH] Refactor bytea_sortsupport(), take two