On Mon, 14 Jun 2021 08:47:40 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
> >>> 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).
> >
> > I agree with your way to fix. However, the progress reporting didn't work
> > because we cannot return from advanceConnectionState to threadRun and just
> > break the loop.
> >
> > + /* otherwise loop over PREPARE_THROTTLE */
> > break;
> >
> > I attached the fixed patch that uses return instead of break, and I confirmed
> > that this made the progress reporting work property.
>
> I'm hesitating to do such a strictural change for a degenerate case linked
> to "insane" parameters, as pg is unlikely to reach 100 million tps, ever.
> It seems to me enough that the command is not blocked in such cases.
Sure. The change from "break" to "return" is just for making the progress
reporting work in the loop, as you mentioned. However, my original intention
is avoiding stuck in a corner-case where a unrealistic parameter was used, and
I agree with you that this change is not so necessary for handling such a
special situation.
Regards,
Yugo Nagata
--
Yugo NAGATA <nagata@sraoss.co.jp>
