Re: pgbench: allow to exit immediately when any client is aborted
On Wed, 30 Aug 2023 10:11:10 +0900 (JST) Tatsuo Ishii 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. > >>> > >>> + > >>> + --exit-on-abort > >>> + > >>> + > >>> +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 -t or > >>> -T option, > >>> +and pgbench will print an incomplete > >>> results > >>> +in this case. > >>> + > >>> + > >>> + > >>> + > >>> > >>> What about inserting "Note that serialization failures or deadlock > >>> failures will not abort client. See >>> 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 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: > >>> + --exit-on-abort 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
Re: pgbench: allow to exit immediately when any client is aborted
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. >>> >>> + >>> + --exit-on-abort >>> + >>> + >>> +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 -t or >>> -T option, >>> +and pgbench will print an incomplete >>> results >>> +in this case. >>> + >>> + >>> + >>> + >>> >>> What about inserting "Note that serialization failures or deadlock >>> failures will not abort client. See >> 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 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: >>> + --exit-on-abort 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
Re: pgbench: allow to exit immediately when any client is aborted
On Thu, 24 Aug 2023 09:15:51 +0900 (JST) Tatsuo Ishii 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. > >> > >> + > >> + --exit-on-abort > >> + > >> + > >> +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 -t or > >> -T option, > >> +and pgbench will print an incomplete > >> results > >> +in this case. > >> + > >> + > >> + > >> + > >> > >> What about inserting "Note that serialization failures or deadlock > >> failures will not abort client. See >> 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 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: > >> + --exit-on-abort 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 diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 6c5c8afa6d..95cc9027c3 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -768,6 +768,24 @@ pgbench options d + + --exit-on-abort + + +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 -t or -T option, +and pgbench will print an incomplete results +in this case. + + +Note that serialization failures or deadlock failures do not abort the +client, so they are not affected by this option. +See for more information. + + + + --failures-detailed @@ -985,7 +1003,8 @@ pgbench options d benchmark such as initial connection failures also exit with status 1. Errors during the run such as database errors or problems in the script will result in exit status 2. In the latter case, - pgbench will print partial results. + pgbench will print partial results if + --exit-on-abort option is not specified. @@ -2801,14 +2820,17 @@ statement latencies in milliseconds, failures and retries: start a connection to the database server / the socket for connecting the client to the database server has become invalid). In such cases all clients of this thread stop while other threads continue to work. + However, --exit-on-abort is specified, all of the + threads stop immediately in this case. Direct client errors. They lead to immediate exit from pgbench with the corresponding error message - only in the case of an internal pgbench - error (which are supposed to never occur...). Otherwise in the worst + in the case of an internal pgbench + error (which are supposed to never occur...) or when + --exit-on-abort is specified. Otherwise in the worst case they only lead to the abortion of the failed client while
Re: pgbench: allow to exit immediately when any client is aborted
>> 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. >> >> + >> + --exit-on-abort >> + >> + >> +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 -t or >> -T option, >> +and pgbench will print an incomplete >> results >> +in this case. >> + >> + >> + >> + >> >> What about inserting "Note that serialization failures or deadlock >> failures will not abort client. See > 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 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: >> + --exit-on-abort 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
Re: pgbench: allow to exit immediately when any client is aborted
On Sat, 19 Aug 2023 19:51:56 +0900 (JST) Tatsuo Ishii 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: > > 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. > > + > + --exit-on-abort > + > + > +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 -t or -T > option, > +and pgbench will print an incomplete > results > +in this case. > + > + > + > + > > What about inserting "Note that serialization failures or deadlock > failures will not abort client. See 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 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: > + --exit-on-abort 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 diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 6c5c8afa6d..4175cf4ccd 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -768,6 +768,24 @@ pgbench options d + + --exit-on-abort + + +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 -t or -T option, +and pgbench will print an incomplete results +in this case. + + +Note that serialization failures or deadlock failures does not abort the +client, so they are not affected by this option. +See for more information. + + + + --failures-detailed @@ -985,7 +1003,8 @@ pgbench options d benchmark such as initial connection failures also exit with status 1. Errors during the run such as database errors or problems in the script will result in exit status 2. In the latter case, - pgbench will print partial results. + pgbench will print partial results if + --exit-on-abort option is not specified. @@ -2801,14 +2820,17 @@ statement latencies in milliseconds, failures and retries: start a connection to the database server / the socket for connecting the client to the database server has become invalid). In such cases all clients of this thread stop while other threads continue to work. + However, --exit-on-abort is specified, all of the + threads stop immediately in this case.
Re: pgbench: allow to exit immediately when any client is aborted
> 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: > 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. + + --exit-on-abort + + +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 -t or -T option, +and pgbench will print an incomplete results +in this case. + + + + What about inserting "Note that serialization failures or deadlock failures will not abort client. See 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: + --exit-on-abort 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
Re: pgbench: allow to exit immediately when any client is aborted
> 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: 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
Re: pgbench: allow to exit immediately when any client is aborted
About pgbench exit on abort v4: Patch applies cleanly, compiles, local make check ok, doc looks ok. This looks ok to me. -- Fabien.
Re: pgbench: allow to exit immediately when any client is aborted
On Sun, 13 Aug 2023 11:27:55 +0200 (CEST)
Fabien COELHO 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
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 6c5c8afa6d..83fe01c33f 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -787,6 +787,19 @@ pgbench options d
+
+ --exit-on-abort
+
+
+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 -t or -T option,
+and pgbench will print an incomplete results
+in this case.
+
+
+
+
--log-prefix=prefix
@@ -985,7 +998,8 @@ pgbench options d
benchmark such as initial connection failures also exit with status 1.
Errors during the run such as database errors or problems in the script
will result in exit status 2. In the latter case,
- pgbench will print partial results.
+ pgbench will print partial results if
+ --exit-on-abort option is not specified.
@@ -2801,14 +2815,17 @@ statement latencies in milliseconds, failures and retries:
start a connection to the database server / the socket for connecting
the client to the database server has become invalid). In such cases
all clients of this thread stop while other threads continue to work.
+ However, --exit-on-abort is specified, all of the
+ threads stop immediately in this case.
Direct client errors. They lead to immediate exit from
pgbench with the corresponding error message
- only in the case of an internal pgbench
- error (which are supposed to never occur...). Otherwise in the worst
+ in the case of an internal pgbench
+ error (which are supposed to never occur...) or when
+ --exit-on-abort is specified . Otherwise in the worst
case they only lead to the abortion of the failed client while other
clients continue their run (but some client errors are handled without
an abortion of the client and reported separately, see below). Later in
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 763c4b946a..4e64a60a63 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -765,6 +765,8 @@ static int64 total_weight = 0;
static bool verbose_errors = false; /* print verbose messages of all errors */
+static bool exit_on_abort = false; /* exit when any client is aborted */
+
/* Builtin test scripts */
typedef struct BuiltinScript
{
@@ -911,6 +913,7 @@ usage(void)
" -T, --time=NUM duration of benchmark test in seconds\n"
" -v, --vacuum-all vacuum all four standard tables before tests\n"
" --aggregate-interval=NUM aggregate data over NUM seconds\n"
+ " --exit-on-abort exit when any client is aborted\n"
" --failures-detailed report the failures grouped by basic types\n"
" --log-prefix=PREFIX prefix for transaction time log file\n"
" (default: \"pgbench_log\")\n"
@@ -6617,6 +6620,7 @@ main(int argc, char **argv)
{"failures-detailed", no_argument, NULL, 13},
{"max-tries", required_argument, NULL, 14},
{"verbose-errors", no_argument, NULL, 15},
+ {"exit-on-abort", no_argument, NULL, 16},
{NULL, 0, NULL, 0}
};
@@ -6950,6 +6954,10 @@ main(int argc, char **argv)
benchmarking_option_set = true;
verbose_errors = true;
break;
+ case 16: /* exit-on-abort */
+benchmarking_option_set = true;
+exit_on_abort = true;
+break;
default:
/* getopt_long already emitted a complaint */
pg_log_error_hint("Try \"%s --help\" for more information.", progname);
@@ -7558,11 +7566,17 @@ threadRun(void *arg)
advanceConnectionState(thread, st, );
+ /*
+ * If --exit-on-abort is used, the program is going to exit
+ * when any client is aborted.
+ */
+ if (exit_on_abort && st->state == CSTATE_ABORTED)
+goto done;
/*
* If advanceConnectionState changed client to finished state,
*
Re: pgbench: allow to exit immediately when any client is aborted
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.
Re: pgbench: allow to exit immediately when any client is aborted
On Wed, 9 Aug 2023 13:59:21 +0900
Yugo NAGATA wrote:
> On Wed, 9 Aug 2023 10:46:38 +0900
> Yugo NAGATA wrote:
>
> > On Wed, 9 Aug 2023 02:15:01 +0200 (CEST)
> > Fabien COELHO 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
> >
> >
>
>
> --
> Yugo NAGATA
--
Yugo NAGATA
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 6c5c8afa6d..83fe01c33f 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -787,6 +787,19 @@ pgbench options d
+
+ --exit-on-abort
+
+
+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 -t or -T option,
+and pgbench will print an incomplete results
+in this case.
+
+
+
+
--log-prefix=prefix
@@ -985,7 +998,8 @@ pgbench options d
benchmark such as initial connection failures also exit with status 1.
Errors during the run such as database errors or problems in the script
will result in exit status 2. In the latter case,
- pgbench will print partial results.
+ pgbench will print partial results if
+ --exit-on-abort option is not specified.
@@ -2801,14 +2815,17 @@ statement latencies in milliseconds, failures and retries:
start a connection to the database server / the socket for connecting
the client to the database server has become invalid). In such cases
all clients of this thread stop while other threads continue to work.
+ However, --exit-on-abort is specified, all of the
+ threads stop immediately in this case.
Direct client errors. They lead to immediate exit from
pgbench with the corresponding error message
- only in the case of an internal pgbench
- error (which are supposed to never occur...). Otherwise in the worst
+ in the case of an internal pgbench
+ error (which are supposed to never occur...) or when
+ --exit-on-abort is specified . Otherwise in the worst
case they only lead to the abortion of the failed client while other
clients continue their run (but some client errors are handled without
an abortion of the client and reported separately, see below). Later in
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 539c2795e2..eca55d0230 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -765,6 +765,8 @@ static int64 total_weight = 0;
static bool verbose_errors = false; /* print verbose messages of all errors */
+static bool exit_on_abort = false; /* exit when any client is aborted */
+
/* Builtin test scripts */
typedef struct BuiltinScript
{
@@ -911,6 +913,7 @@ usage(void)
" -T, --time=NUM duration of benchmark test in seconds\n"
" -v, --vacuum-all vacuum all four standard tables before tests\n"
" --aggregate-interval=NUM aggregate data over NUM seconds\n"
+ " --exit-on-abort exit when any client is aborted\n"
" --failures-detailed report the failures grouped by basic types\n"
" --log-prefix=PREFIX prefix for transaction time log file\n"
" (default: \"pgbench_log\")\n"
@@ -6612,6 +6615,7 @@ main(int argc, char **argv)
{"failures-detailed", no_argument, NULL, 13},
{"max-tries", required_argument, NULL, 14},
{"verbose-errors", no_argument, NULL, 15},
Re: pgbench: allow to exit immediately when any client is aborted
On Wed, 9 Aug 2023 10:46:38 +0900
Yugo NAGATA wrote:
> On Wed, 9 Aug 2023 02:15:01 +0200 (CEST)
> Fabien COELHO 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
>
>
--
Yugo NAGATA
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 6c5c8afa6d..83fe01c33f 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -787,6 +787,19 @@ pgbench options d
+
+ --exit-on-abort
+
+
+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 -t or -T option,
+and pgbench will print an incomplete results
+in this case.
+
+
+
+
--log-prefix=prefix
@@ -985,7 +998,8 @@ pgbench options d
benchmark such as initial connection failures also exit with status 1.
Errors during the run such as database errors or problems in the script
will result in exit status 2. In the latter case,
- pgbench will print partial results.
+ pgbench will print partial results if
+ --exit-on-abort option is not specified.
@@ -2801,14 +2815,17 @@ statement latencies in milliseconds, failures and retries:
start a connection to the database server / the socket for connecting
the client to the database server has become invalid). In such cases
all clients of this thread stop while other threads continue to work.
+ However, --exit-on-abort is specified, all of the
+ threads stop immediately in this case.
Direct client errors. They lead to immediate exit from
pgbench with the corresponding error message
- only in the case of an internal pgbench
- error (which are supposed to never occur...). Otherwise in the worst
+ in the case of an internal pgbench
+ error (which are supposed to never occur...) or when
+ --exit-on-abort is specified . Otherwise in the worst
case they only lead to the abortion of the failed client while other
clients continue their run (but some client errors are handled without
an abortion of the client and reported separately, see below). Later in
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 539c2795e2..eca55d0230 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -765,6 +765,8 @@ static int64 total_weight = 0;
static bool verbose_errors = false; /* print verbose messages of all errors */
+static bool exit_on_abort = false; /* exit when any client is aborted */
+
/* Builtin test scripts */
typedef struct BuiltinScript
{
@@ -911,6 +913,7 @@ usage(void)
" -T, --time=NUM duration of benchmark test in seconds\n"
" -v, --vacuum-all vacuum all four standard tables before tests\n"
" --aggregate-interval=NUM aggregate data over NUM seconds\n"
+ " --exit-on-abort exit when any client is aborted\n"
" --failures-detailed report the failures grouped by basic types\n"
" --log-prefix=PREFIX prefix for transaction time log file\n"
" (default: \"pgbench_log\")\n"
@@ -6612,6 +6615,7 @@ main(int argc, char **argv)
{"failures-detailed", no_argument, NULL, 13},
{"max-tries", required_argument, NULL, 14},
{"verbose-errors", no_argument, NULL, 15},
+ {"exit-on-abort", no_argument, NULL, 16},
{NULL, 0, NULL, 0}
};
@@ -6945,6 +6949,10 @@ main(int argc, char **argv)
benchmarking_option_set = true;
verbose_errors = true;
break;
+ case 16: /* exit-on-abort */
+benchmarking_option_set = true;
+
Re: pgbench: allow to exit immediately when any client is aborted
On Wed, 9 Aug 2023 02:15:01 +0200 (CEST) Fabien COELHO 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
Re: pgbench: allow to exit immediately when any client is aborted
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.
Re: pgbench: allow to exit immediately when any client is aborted
Hello Fabien, On Mon, 7 Aug 2023 12:17:38 +0200 (CEST) Fabien COELHO 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
Re: pgbench: allow to exit immediately when any client is aborted
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.
Re: pgbench: allow to exit immediately when any client is aborted
On Mon, 7 Aug 2023 11:02:48 +0900 Yugo NAGATA wrote: > On Sat, 05 Aug 2023 12:16:11 +0900 (JST) > Tatsuo Ishii 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 > > -- Yugo NAGATA diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 6c5c8afa6d..83fe01c33f 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -787,6 +787,19 @@ pgbench options d + + --exit-on-abort + + +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 -t or -T option, +and pgbench will print an incomplete results +in this case. + + + + --log-prefix=prefix @@ -985,7 +998,8 @@ pgbench options d benchmark such as initial connection failures also exit with status 1. Errors during the run such as database errors or problems in the script will result in exit status 2. In the latter case, - pgbench will print partial results. + pgbench will print partial results if + --exit-on-abort option is not specified. @@ -2801,14 +2815,17 @@ statement latencies in milliseconds, failures and retries: start a connection to the database server / the socket for connecting the client to the database server has become invalid). In such cases all clients of this thread stop while other threads continue to work. + However, --exit-on-abort is specified, all of the + threads stop immediately in this case. Direct client errors. They lead to immediate exit from pgbench with the corresponding error message - only in the case of an internal pgbench - error (which are supposed to never occur...). Otherwise in the worst + in the case of an internal pgbench + error (which are supposed to never occur...) or when + --exit-on-abort is specified . Otherwise in the worst case they only lead to the abortion of the failed client while other clients continue their run (but some client errors are handled without an abortion of the client and reported separately, see below). Later in diff --git a/src/bin/pgbench/pgbench.c
Re: pgbench: allow to exit immediately when any client is aborted
On Sat, 05 Aug 2023 12:16:11 +0900 (JST) Tatsuo Ishii 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
Re: 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
