pgbench: allow to exit immediately when any client is aborted

Hi,

I would like to propose to add an option to pgbench so that benchmark
can quit immediately when any client is aborted. Currently, when a
client is aborted due to some error, for example, network trouble,
other clients continue their run until a certain number of transactions
specified -t is reached or the time specified by -T is expired. At the
end, the results are printed, but they are not useful, as the message
"Run was aborted; the above results are incomplete" shows.

Sounds like a good idea. It's a waste of resources waiting for
unusable benchmark results until t/T expired. If we graze on the
screen, then it's easy to cancel the pgbench run. But I frequently let
pgbench run without sitting in front of the screen especially when t/T
is large (it's recommended that running pgbench with large enough t/T
to get usable results).

For precise benchmark purpose, we would not want to wait to get such
incomplete results, rather we would like to know some trouble happened
to allow a quick retry. Therefore, it would be nice to add an option to
make pgbench exit instead of continuing run in other clients when any
client is aborted. I think adding the optional is better than whole
behavioural change because some users that use pgbench just in order
to stress on backends for testing purpose rather than benchmark might
not want to stop pgbench even a client is aborted.

Attached is the patch to add the option --exit-on-abort.
If this option is specified, when any client is aborted, pgbench
immediately quit by calling exit(2).

What do you think about it?

I think aborting pgbench by calling exit(2) is enough. It's not worth
the trouble to add more codes for this purpose.

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

On Sat, 05 Aug 2023 12:16:11 +0900 (JST)
Tatsuo Ishii <ishii@sraoss.co.jp> wrote:

Hi,

I would like to propose to add an option to pgbench so that benchmark
can quit immediately when any client is aborted. Currently, when a
client is aborted due to some error, for example, network trouble,
other clients continue their run until a certain number of transactions
specified -t is reached or the time specified by -T is expired. At the
end, the results are printed, but they are not useful, as the message
"Run was aborted; the above results are incomplete" shows.

Sounds like a good idea. It's a waste of resources waiting for
unusable benchmark results until t/T expired. If we graze on the
screen, then it's easy to cancel the pgbench run. But I frequently let
pgbench run without sitting in front of the screen especially when t/T
is large (it's recommended that running pgbench with large enough t/T
to get usable results).

Thank you for your agreement.

For precise benchmark purpose, we would not want to wait to get such
incomplete results, rather we would like to know some trouble happened
to allow a quick retry. Therefore, it would be nice to add an option to
make pgbench exit instead of continuing run in other clients when any
client is aborted. I think adding the optional is better than whole
behavioural change because some users that use pgbench just in order
to stress on backends for testing purpose rather than benchmark might
not want to stop pgbench even a client is aborted.

Attached is the patch to add the option --exit-on-abort.
If this option is specified, when any client is aborted, pgbench
immediately quit by calling exit(2).

What do you think about it?

I think aborting pgbench by calling exit(2) is enough. It's not worth
the trouble to add more codes for this purpose.

In order to stop pgbench more gracefully, it might be better to make
each thread exit at more proper timing after some cleaning-up like
connection close. However, pgbench code doesn't provide such functions
for inter-threads communication. If we would try to make this, both
pthread and Windows versions would be needed. I don't think it is necessary
to make such effort for --exit-on-abort option, as you said.

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>

On Mon, 7 Aug 2023 11:02:48 +0900
Yugo NAGATA <nagata@sraoss.co.jp> wrote:

On Sat, 05 Aug 2023 12:16:11 +0900 (JST)
Tatsuo Ishii <ishii@sraoss.co.jp> wrote:

Hi,

I would like to propose to add an option to pgbench so that benchmark
can quit immediately when any client is aborted. Currently, when a
client is aborted due to some error, for example, network trouble,
other clients continue their run until a certain number of transactions
specified -t is reached or the time specified by -T is expired. At the
end, the results are printed, but they are not useful, as the message
"Run was aborted; the above results are incomplete" shows.

Sounds like a good idea. It's a waste of resources waiting for
unusable benchmark results until t/T expired. If we graze on the
screen, then it's easy to cancel the pgbench run. But I frequently let
pgbench run without sitting in front of the screen especially when t/T
is large (it's recommended that running pgbench with large enough t/T
to get usable results).

Thank you for your agreement.

For precise benchmark purpose, we would not want to wait to get such
incomplete results, rather we would like to know some trouble happened
to allow a quick retry. Therefore, it would be nice to add an option to
make pgbench exit instead of continuing run in other clients when any
client is aborted. I think adding the optional is better than whole
behavioural change because some users that use pgbench just in order
to stress on backends for testing purpose rather than benchmark might
not want to stop pgbench even a client is aborted.

Attached is the patch to add the option --exit-on-abort.
If this option is specified, when any client is aborted, pgbench
immediately quit by calling exit(2).

I attached v2 patch including the documentation and some comments
in the code.

Regards,
Yugo Nagata

What do you think about it?

I think aborting pgbench by calling exit(2) is enough. It's not worth
the trouble to add more codes for this purpose.

In order to stop pgbench more gracefully, it might be better to make
each thread exit at more proper timing after some cleaning-up like
connection close. However, pgbench code doesn't provide such functions
for inter-threads communication. If we would try to make this, both
pthread and Windows versions would be needed. I don't think it is necessary
to make such effort for --exit-on-abort option, as you said.

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>

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

Hello Yugo-san,

I attached v2 patch including the documentation and some comments
in the code.

I've looked at this patch.

I'm unclear whether it does what it says: "exit immediately on abort", I
would expect a cold call to "exit" (with a clear message obviously) when
the abort occurs.

Currently it skips to "done" which starts by closing this particular
thread client connections, then it will call "exit" later, so it is not
"immediate".

I do not think that this cleanup is necessary, because anyway all other
threads will be brutally killed by the exit called by the aborted thread,
so why bothering to disconnect only some connections?

/* If any client is aborted, exit immediately. */
if (state[i].state != CSTATE_FINISHED)

For this comment, I would prefer "if ( ... == CSTATE_ABORTED)" rather that
implying that not finished means aborted, and if you follow my previous
remark then this code can be removed.

Typo: "going to exist" -> "going to exit". Note that it is not "the whole
thread" but "the program" which is exiting.

There is no test.

--
Fabien.

Hello Fabien,

On Mon, 7 Aug 2023 12:17:38 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello Yugo-san,

I attached v2 patch including the documentation and some comments
in the code.

I've looked at this patch.

Thank you for your review!

I'm unclear whether it does what it says: "exit immediately on abort", I
would expect a cold call to "exit" (with a clear message obviously) when
the abort occurs.

Currently it skips to "done" which starts by closing this particular
thread client connections, then it will call "exit" later, so it is not
"immediate".

There are cases where "goto done" is used where some error like
"invalid socket: ..." happens. I would like to make pgbench exit in
such cases, too, so I chose to handle errors below the "done:" label.
However, we can change it to call "exit" instead of "goo done" at each
place. Do you think this is better?

I do not think that this cleanup is necessary, because anyway all other
threads will be brutally killed by the exit called by the aborted thread,
so why bothering to disconnect only some connections?

Agreed. This disconnection is not necessary anyway even when we would like
to handle it below "done".

/* If any client is aborted, exit immediately. */
if (state[i].state != CSTATE_FINISHED)

For this comment, I would prefer "if ( ... == CSTATE_ABORTED)" rather that
implying that not finished means aborted, and if you follow my previous
remark then this code can be removed.

Ok. If we handle errors like "invalid socket:" (mentioned above) after
skipping to "done", we should set the status to CSTATE_ABORTED before the jump.
Otherwise, if we choose to call "exit" immediately at each error instead of
skipping to "done", we can remove this as you says.

Typo: "going to exist" -> "going to exit". Note that it is not "the whole
thread" but "the program" which is exiting.

I'll fix.

There is no test.

I'll add an test.

Regards,
Yugo Nagata

--
Fabien.

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

Hello Yugo-san,

There are cases where "goto done" is used where some error like
"invalid socket: ..." happens. I would like to make pgbench exit in
such cases, too, so I chose to handle errors below the "done:" label.
However, we can change it to call "exit" instead of "goo done" at each
place. Do you think this is better?

Good point.

Now I understand the "!= FINISHED", because indeed in these cases the done
is reached with unfinished but not necessarily ABORTED clients, and the
comment was somehow misleading.

On reflection, there should be only one exit() call, thus I'd say to keep
the "goto done" as you did, but to move the checking loop *before* the
disconnect_all, and the overall section comment could be something like
"possibly abort if any client is not finished, meaning some error
occured", which is consistent with the "!= FINISHED" condition.

--
Fabien.

On Wed, 9 Aug 2023 02:15:01 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello Yugo-san,

There are cases where "goto done" is used where some error like
"invalid socket: ..." happens. I would like to make pgbench exit in
such cases, too, so I chose to handle errors below the "done:" label.
However, we can change it to call "exit" instead of "goo done" at each
place. Do you think this is better?

Good point.

Now I understand the "!= FINISHED", because indeed in these cases the done
is reached with unfinished but not necessarily ABORTED clients, and the
comment was somehow misleading.

On reflection, there should be only one exit() call, thus I'd say to keep
the "goto done" as you did, but to move the checking loop *before* the
disconnect_all, and the overall section comment could be something like
"possibly abort if any client is not finished, meaning some error
occured", which is consistent with the "!= FINISHED" condition.

Thank you for your suggestion.
I'll fix as above and submit a updated patch soon.

Regards,
Yugo Nagata

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

On Wed, 9 Aug 2023 10:46:38 +0900
Yugo NAGATA <nagata@sraoss.co.jp> wrote:

On Wed, 9 Aug 2023 02:15:01 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello Yugo-san,

There are cases where "goto done" is used where some error like
"invalid socket: ..." happens. I would like to make pgbench exit in
such cases, too, so I chose to handle errors below the "done:" label.
However, we can change it to call "exit" instead of "goo done" at each
place. Do you think this is better?

Good point.

Now I understand the "!= FINISHED", because indeed in these cases the done
is reached with unfinished but not necessarily ABORTED clients, and the
comment was somehow misleading.

On reflection, there should be only one exit() call, thus I'd say to keep
the "goto done" as you did, but to move the checking loop *before* the
disconnect_all, and the overall section comment could be something like
"possibly abort if any client is not finished, meaning some error
occured", which is consistent with the "!= FINISHED" condition.

Thank you for your suggestion.
I'll fix as above and submit a updated patch soon.

I attached the updated patch v3 including changes above, a test,
and fix of the typo you pointed out.

Regards,
Yugo Nagata

Regards,
Yugo Nagata

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

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

On Wed, 9 Aug 2023 13:59:21 +0900
Yugo NAGATA <nagata@sraoss.co.jp> wrote:

On Wed, 9 Aug 2023 10:46:38 +0900
Yugo NAGATA <nagata@sraoss.co.jp> wrote:

On Wed, 9 Aug 2023 02:15:01 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello Yugo-san,

There are cases where "goto done" is used where some error like
"invalid socket: ..." happens. I would like to make pgbench exit in
such cases, too, so I chose to handle errors below the "done:" label.
However, we can change it to call "exit" instead of "goo done" at each
place. Do you think this is better?

Good point.

Now I understand the "!= FINISHED", because indeed in these cases the done
is reached with unfinished but not necessarily ABORTED clients, and the
comment was somehow misleading.

On reflection, there should be only one exit() call, thus I'd say to keep
the "goto done" as you did, but to move the checking loop *before* the
disconnect_all, and the overall section comment could be something like
"possibly abort if any client is not finished, meaning some error
occured", which is consistent with the "!= FINISHED" condition.

Thank you for your suggestion.
I'll fix as above and submit a updated patch soon.

I attached the updated patch v3 including changes above, a test,
and fix of the typo you pointed out.

I'm sorry but the test in the previous patch was incorrect.
I attached the correct one.

Regards,
Yugo Nagata

Regards,
Yugo Nagata

Regards,
Yugo Nagata

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

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

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

Hello Yugo-san,

I attached the updated patch v3 including changes above, a test,
and fix of the typo you pointed out.

I'm sorry but the test in the previous patch was incorrect.
I attached the correct one.

About pgbench exit on abort v3:

Patch does not "git apply", but is ok with "patch" although there are some
minor warnings.

Compiles. Code is ok. Tests are ok.

About Test:

The code is simple to get an error quickly but after a few transactions,
good. I'll do a minimal "-c 2 -j 2 -t 10" instead of "-c 4 -j 4 -T 10".

--
Fabien.

On Sun, 13 Aug 2023 11:27:55 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello Yugo-san,

I attached the updated patch v3 including changes above, a test,
and fix of the typo you pointed out.

I'm sorry but the test in the previous patch was incorrect.
I attached the correct one.

About pgbench exit on abort v3:

Patch does not "git apply", but is ok with "patch" although there are some
minor warnings.

In my environment, the patch can be applied to the master branch without
any warnings...

Compiles. Code is ok. Tests are ok.

About Test:

The code is simple to get an error quickly but after a few transactions,
good. I'll do a minimal "-c 2 -j 2 -t 10" instead of "-c 4 -j 4 -T 10".

I fixed the test and attached the updated patch, v4.

Regards,
Yugo Nagata

--
Fabien.

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

About pgbench exit on abort v4:

Patch applies cleanly, compiles, local make check ok, doc looks ok.

This looks ok to me.

--
Fabien.

About pgbench exit on abort v4:

Patch applies cleanly, compiles, local make check ok, doc looks ok.

This looks ok to me.

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?

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

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?

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?

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)

Also:
+ <option>--exit-on-abort</option> is specified . Otherwise in the worst

There is an extra space between "specified" and ".".

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

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>

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.

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

On Thu, 24 Aug 2023 09:15:51 +0900 (JST)
Tatsuo Ishii <ishii@sraoss.co.jp> wrote:

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.

Ok.

"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".

Oops. I attached the updated patch.

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.

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>

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!

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

On Wed, 30 Aug 2023 10:11:10 +0900 (JST)
Tatsuo Ishii <ishii@sraoss.co.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@sraoss.co.jp>