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  (Greg Sabino Mullane <htamfids@gmail.com>)
Re: Avoid stuck of pbgench due to skipped transactions  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: PoC: Using Count-Min Sketch for join cardinality estimation
Следующее
От: John Naylor
Дата:
Сообщение: Re: a path towards replacing GEQO with something better