From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Avoid stuck of pbgench due to skipped transactions |
Date: | 2021-06-13 06:56:59 |
Message-ID: | alpine.DEB.2.22.394.2106122339210.479449@pseudo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Yugo-san,
> For example, when I usee a large rate (-R) for throttling and a
> small latency limit (-L) values with a duration (-T), pbbench
> got stuck.
>
> $ pgbench -T 5 -R 100000000 -L 1;
Indeed, it does not get out of the catchup loop for a long time because
even scheduling takes more time than the expected transaction time!
> I think it is better to check the timer expiration even in the loop
> of transaction skips and to finish pgbnech successfully because we
> should correcly repport how many transactions are proccessed and
> skipped also in this case, and getting stuck would not be good
> anyway.
>
> I attached a patch for this fix.
The patch mostly works for me, and I agree that the bench should not be in
a loop on any parameters, even when "crazy" parameters are given…
However I'm not sure this is the right way to handle this issue.
The catch-up loop can be dropped and the automaton can loop over itself to
reschedule. Doing that as the attached fixes this issue and also makes
progress reporting work proprely in more cases, and reduces the number of
lines of code. I did not add a test case because time sensitive tests have
been removed (which is too bad, IMHO).
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
pgbench-stuck-2.patch | text/x-diff | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2021-06-13 07:34:07 | Re: Continuing instability in insert-conflict-specconflict test |
Previous Message | Geoff Winkless | 2021-06-13 06:36:54 | Re: "an SQL" vs. "a SQL" |