| From: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
| Cc: | thomas(dot)munro(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Retry in pgbench |
| Date: | 2021-04-16 13:09:36 |
| Message-ID: | 20210416150936.6c22e77e@firost |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 16 Apr 2021 10:28:48 +0900 (JST)
Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:
> > By the way, I've been playing with the idea of failing gracefully and retry
> > indefinitely (or until given -T) on SQL error AND connection issue.
> >
> > It would be useful to test replicating clusters with a (switch|fail)over
> > procedure.
>
> Interesting idea but in general a failover takes sometime (like a few
> minutes), and it will strongly affect TPS. I think in the end it just
> compares the failover time.
This usecase is not about benchmarking. It's about generating constant trafic
to be able to practice/train some [auto]switchover procedures while being close
to production activity.
In this contexte, a max-saturated TPS of one node is not relevant. But being
able to add some stats about downtime might be a good addition.
Regards,
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2021-04-16 13:15:08 | Re: Retry in pgbench |
| Previous Message | Amit Kapila | 2021-04-16 12:05:42 | Re: WIP: WAL prefetch (another approach) |