Re: Avoid stuck of pbgench due to skipped transactions
| От | Yugo NAGATA |
|---|---|
| Тема | Re: Avoid stuck of pbgench due to skipped transactions |
| Дата | |
| Msg-id | 20210617012349.8a429a88bca86bee2e5e49e8@sraoss.co.jp обсуждение исходный текст |
| Ответ на | Re: Avoid stuck of pbgench due to skipped transactions (Yugo NAGATA <nagata@sraoss.co.jp>) |
| Ответы |
Re: Avoid stuck of pbgench due to skipped transactions
Re: Avoid stuck of pbgench due to skipped transactions |
| Список | pgsql-hackers |
On Mon, 14 Jun 2021 16:06:10 +0900 Yugo NAGATA <nagata@sraoss.co.jp> wrote: > On Mon, 14 Jun 2021 08:47:40 +0200 (CEST) > Fabien COELHO <coelho@cri.ensmp.fr> wrote: > > > 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. I attached the v2 patch to clarify that I withdrew the v3 patch. Regards Yugo Nagata -- Yugo NAGATA <nagata@sraoss.co.jp>
Вложения
В списке pgsql-hackers по дате отправления: