Re: Avoid stuck of pbgench due to skipped transactions

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoid stuck of pbgench due to skipped transactions
Date: 2021-06-16 16:23:49
Message-ID: 20210617012349.8a429a88bca86bee2e5e49e8@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 14 Jun 2021 16:06:10 +0900
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote:

> On Mon, 14 Jun 2021 08:47:40 +0200 (CEST)
> Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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(at)sraoss(dot)co(dot)jp>

Attachment Content-Type Size
pgbench-stuck-2.patch text/x-diff 1.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2021-06-16 16:24:05 Re: a path towards replacing GEQO with something better
Previous Message Tomas Vondra 2021-06-16 16:23:28 PoC: Using Count-Min Sketch for join cardinality estimation