Re: pgbench: allow to exit immediately when any client is aborted - Mailing list pgsql-hackers

On Sat, 19 Aug 2023 19:51:56 +0900 (JST)
Tatsuo Ishii <ishii@sraoss.co.jp> wrote:

> > I have tested the v4 patch with default_transaction_isolation =
> > 'repeatable read'.
> > 
> > pgbench --exit-on-abort -N -p 11002 -c 10 -T 30 test
> > pgbench (17devel, server 15.3)
> > starting vacuum...end.
> > transaction type: <builtin: simple update>
> > scaling factor: 1
> > query mode: simple
> > number of clients: 10
> > number of threads: 1
> > maximum number of tries: 1
> > duration: 30 s
> > number of transactions actually processed: 64854
> > number of failed transactions: 4 (0.006%)
> > latency average = 4.628 ms (including failures)
> > initial connection time = 49.526 ms
> > tps = 2160.827556 (without initial connection time)
> > 
> > Depite the 4 failed transactions (could not serialize access due to
> > concurrent update) pgbench ran normally, rather than aborting the
> > test. Is this an expected behavior?

Yes. --exit-on-abort changes a behaviour when a client is **aborted**
due to an error, and serialization errors do not cause abort, so
it is not affected.

> I start to think this behavior is ok and consistent with previous
> behavior of pgbench because serialization (and dealock) errors have
> been treated specially from other types of errors, such as accessing
> non existing tables. However, I suggest to add more sentences to the
> explanation of this option so that users are not confused by this.
> 
> +     <varlistentry id="pgbench-option-exit-on-abort">
> +      <term><option>--exit-on-abort</option></term>
> +      <listitem>
> +       <para>
> +        Exit immediately when any client is aborted due to some error. Without
> +        this option, even when a client is aborted, other clients could continue
> +        their run as specified by <option>-t</option> or <option>-T</option> option,
> +        and <application>pgbench</application> will print an incomplete results
> +        in this case.
> +       </para>
> +      </listitem>
> +     </varlistentry>
> +
> 
> What about inserting "Note that serialization failures or deadlock
> failures will not abort client.  See <xref
> linkend="failures-and-retries"/> for more information." into the end
> of this paragraph?

--exit-on-abort is related to "abort" of a client instead of error or
failure itself, so rather I wonder a bit that mentioning serialization/deadlock
failures might be  confusing. However, if users may think of such failures from
"abort", it could be beneficial to add the sentences with some modification as
below.

 "Note that serialization failures or deadlock failures does not abort the
  client, so they are not affected by this option.
  See <xref linkend="failures-and-retries"/> for more information."

> BTW, I think:
>         Exit immediately when any client is aborted due to some error. Without
> 
> should be:
>         Exit immediately when any client is aborted due to some errors. Without
> 
> (error vs. erros)

Well, I chose "some" to mean "unknown or unspecified", not "an unspecified amount
or number of", so singular form "error" is used. 
Instead, should we use "due to a error"?

> Also:
> +         <option>--exit-on-abort</option> is specified . Otherwise in the worst
> 
> There is an extra space between "specified" and ".".

Fixed.

Also, I fixed the place of the description in the documentation
to alphabetical order

Attached is the updated patch. 

Regards,
Yugo Nagata

> 
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp


-- 
Yugo NAGATA <nagata@sraoss.co.jp>