Re: Avoid stuck of pbgench due to skipped transactions
От | Fabien COELHO |
---|---|
Тема | Re: Avoid stuck of pbgench due to skipped transactions |
Дата | |
Msg-id | alpine.DEB.2.22.394.2106140830320.1338009@pseudo обсуждение исходный текст |
Ответ на | Re: Avoid stuck of pbgench due to skipped transactions (Yugo NAGATA <nagata@sraoss.co.jp>) |
Ответы |
Re: Avoid stuck of pbgench due to skipped transactions
|
Список | pgsql-hackers |
>>> 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. -- Fabien.
В списке pgsql-hackers по дате отправления: