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.2109040817460.2329925@pseudo обсуждение исходный текст |
Ответ на | Re: Avoid stuck of pbgench due to skipped transactions (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: Avoid stuck of pbgench due to skipped transactions
|
Список | pgsql-hackers |
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 there for some possibly long time. > On the other hand, even without the patch, in the first place, there seems > no guarantee that all the skipped transactions are counted under -T. > When the timer is exceeded in CSTATE_END_TX, a client ends without > checking outstanding skipped transactions. Indeed. But that should be very few transactions under latency limit. > Therefore the "issue" that some skipped transactions are not counted is > not one the patch newly introdues. Yep. The patch counts less of them though, because of the early exit introduced in the patch in the scheduling state. Before it could be stuck in the "while (late) { count; schedule; }" loop. > So that behavior change by the patch would be acceptable. Is this > understanding right? I think so. -- Fabien.
В списке pgsql-hackers по дате отправления: