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 |
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 |