> On Thu, Jul 19, 2018 at 2:24 AM Fabien COELHO <coe...@cri.ensmp.fr> wrote: > > > Hello Heikki, > > >> [...] > >> So threadRun() would not have the opportunity to stop the scheduled > >> transaction, even if beyond the end of run, because it would not have got > >> out of doCustom, in the case I outlined above. > > > > I see. Instead of moving to FINISHED state, then, we could stay in THROTTLE > > state, and 'return' out of doCustom(), to give the code in threadRun() a > > chance to detect that the timer is up. Something like the attached. (I moved > > the check after the check for latency_limit, because that code updates > > txn_scheduled. Seems more like a more correct place, although that's as a > > separate issue.) > > Although I think it would works, I do not find it better than the previous > situation: Before the change throttling simply jumps to finished if time > is up, while with that option the jump cannot be seen from within doCustom > and relies on threadRun to do so, which is somehow much harder to see from > the code because things happen in two functions. > > I would rather move state changes from threadRun to doCustom only, so that > they are all in one place where it is easier to check and understand. > > As a PoC, see attached which does that and also records all stats instead > of trying to be clever, and tries to homogeneise comments somehow. As I > find it strange that a script can be interrupted in sleep and after a > shell command, but not in other states, rather documents that once it > started it will run to its end, and only cut it out before or after, but > not within. Also, there are no state changes outside doCustom, and > threadRun only looks at the states for decisions.
Unfortunately, there was no activity over the last few commitfests and the proposed patch pgbench-tap-progress-6 can't be applied anymore without conflicts. Fabien, what are your plans about it, could you please post a rebased version?
