Re: pgbench: allow to exit immediately when any client is aborted

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org, coelho(at)cri(dot)ensmp(dot)fr
Subject: Re: pgbench: allow to exit immediately when any client is aborted
Date: 2023-08-30 01:55:56
Message-ID: 20230830105556.0da90ebf5e1bcecfcc19de00@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 30 Aug 2023 10:11:10 +0900 (JST)
Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:

> Yugo,
> Fabien,
>
> >>> 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.
> >
> > I myself confused by this and believe that adding extra paragraph is
> > beneficial to users.
> >
> >> "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."
> >
> > "does not" --> "do not".
> >
> >>> 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.
> >
> > Ok.
> >
> >> Instead, should we use "due to a error"?
> >
> > I don't think so.
> >
> >>> 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.
> >
> > Looks good to me. If there's no objection, I will commit this next week.
>
> I have pushed the patch. Thank you for the conributions!

Thank you!

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(at)sraoss(dot)co(dot)jp>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-08-30 02:01:51 Re: pg_stat_get_backend_subxact() and backend IDs?
Previous Message Richard Guo 2023-08-30 01:50:17 Re: Fix shadow warnings in logical replication code