Re: Suggestion to add --continue-client-on-abort option to pgbench
Yugo Nagata <nagata@sraoss.co.jp>
From: Yugo Nagata <nagata@sraoss.co.jp>
To: Chao Li <li.evan.chao@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Rintaro Ikeda
<ikedarintarof@oss.nttdata.com>, Jakub Wartak
<jakub.wartak@enterprisedb.com>, "Hayato Kuroda (Fujitsu)"
<kuroda.hayato@fujitsu.com>, "slpmcf@gmail.com" <slpmcf@gmail.com>,
"boekewurm+postgres@gmail.com" <boekewurm+postgres@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Srinath
Reddy Sadipiralla <srinath2133@gmail.com>, Dilip Kumar
<dilipbalaut@gmail.com>
Date: 2025-11-13T09:40:36Z
Lists: pgsql-hackers
On Thu, 13 Nov 2025 16:13:30 +0800 Chao Li <li.evan.chao@gmail.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@sraoss.co.jp>