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

Hi,

Thank you very much for your valuable comments and kind advice. I'm 
currently working on revising the previous patch based on the feedback 
received. I would like to share my thoughts regarding the conditions 
under which the --continue-on-error option should initiate a new 
transaction or a new connection.

In my opinion, when the --continue-on-error option is enabled, pgbench 
clients does not need to start new transactions after network errors and 
other errors except for SQL-level errors.

Network errors are relatively rare, except in failover scenarios. 
Outside of failover, any network issues should be resolved rather than 
worked around. In the context of failover, the key metric is not TPS, 
but system downtime. While one might infer the timing of a failover by 
observing by using --progress option, you can easily determine the 
downtime by executing simple SQL query such as `psql -c 'SELECT 1` every 
second.


On 2025/06/26 18:47, Yugo Nagata wrote:
> On Thu, 26 Jun 2025 05:45:12 +0000
> "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com> wrote:
> 
>> Dear Nagata-san,
>> 
>>> As I understand it, the current patch aims to allow continuation only 
>>> after
>>> SQL-level
>>> errors, such as constraint violations. That seems reasonable, as it 
>>> can simulate
>>> the
>>> behavior of applications that ignore or retry such errors (even 
>>> though retries are
>>> not
>>> implemented in the current patch).
>> 
>> Yes, no one has objections to retry in this case. This is a main part 
>> of the proposal.,
> 
> As I understand it, the proposed --continue-on-error option does not 
> retry the transaction
> in any case; it simply gives up on the transaction. That is, when an 
> SQL-level error occurs,
> the transaction is reported as "failed" rather than "retried", and the 
> random state is discarded.

Retrying the failed transaction is not necessary when the transaction 
failed due to SQL-level errors. Unlike real-world applications, pgbench 
does not need to complete specific transaction successfully. In the case 
of unique constraint violations, retrying the same transaction will 
likely to result in the same error again.

I want to hear your thoughts on this.

Best regards,
Rintaro Ikeda