Re: Avoid stuck of pbgench due to skipped transactions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoid stuck of pbgench due to skipped transactions
Date: 2021-09-04 06:27:00
Message-ID: alpine.DEB.2.22.394.2109040817460.2329925@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-09-04 09:51:14 Re: using an end-of-recovery record in all cases
Previous Message Noah Misch 2021-09-04 06:19:49 Re: Postgres perl module namespace