Re: Avoid stuck of pbgench due to skipped transactions

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Avoid stuck of pbgench due to skipped transactions
Дата
Msg-id a1bac80e-2714-9a50-67bd-e0c6c015dc05@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: Avoid stuck of pbgench due to skipped transactions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: Avoid stuck of pbgench due to skipped transactions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers

On 2021/09/04 15:27, Fabien COELHO wrote:
> 
> Hello Fujii-san,
> 
>> ISTM that the patch changes pgbench so that it can skip counting
>> some skipped transactions here even for realistic rates under -T.
>> Of course, which would happen very rarely. Is this understanding right?
> 
> Yes. The point is to get out of the scheduling loop when time has expired, as soon it is known, instead of looping
therefor some possibly long time.
 

Thanks for checking my understanding!

+                             * For very unrealistic rates under -T, some skipped
+                             * transactions are not counted because the catchup
+                             * loop is not fast enough just to do the scheduling
+                             * and counting at the expected speed.
+                             *
+                             * We do not bother with such a degenerate case.

So this comment is a bit misleading? What about updating this as follows?

------------------------------
Stop counting skipped transactions under -T as soon as the timer is exceeded.
Because otherwise it can take a very long time to count all of them especially
when quite a lot of them happen with unrealistically high rate setting in -R,
which would prevent pgbench from ending immediately. Because of this behavior,
note that there is no guarantee that all skipped transactions are counted
under -T though there is under -t. This is OK in practice because it's very
unlikely to happen with realistic setting.
------------------------------


>> So that behavior change by the patch would be acceptable. Is this understanding right?
> 
> I think so.

+1

One question is; which version do we want to back-patch to?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Timeout failure in 019_replslot_limit.pl
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: ORDER BY pushdowns seem broken in postgres_fdw