Re: Retry in pgbench

2021-04-16 Thread Tatsuo Ishii
> 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 a

Re: Retry in pgbench

2021-04-16 Thread Jehan-Guillaume de Rorthais
On Fri, 16 Apr 2021 10:28:48 +0900 (JST) Tatsuo Ishii 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 >

Re: Retry in pgbench

2021-04-15 Thread Fabien COELHO
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. Or are you suggesting to ignore the time

Re: Retry in pgbench

2021-04-15 Thread Tatsuo Ishii
> 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 (

Re: Retry in pgbench

2021-04-13 Thread Jehan-Guillaume de Rorthais
Hi, On Tue, 13 Apr 2021 16:12:59 +0900 (JST) Tatsuo Ishii wrote: > [...] > [...] > [...] > > Thanks for the pointer. It seems we need to resume the discussion. By the way, I've been playing with the idea of failing gracefully and retry indefinitely (or until given -T) on SQL error AND

Re: Retry in pgbench

2021-04-13 Thread Tatsuo Ishii
> On Tue, Apr 13, 2021 at 5:51 PM Tatsuo Ishii wrote: >> Currently standard pgbench scenario produces transaction serialize >> errors "could not serialize access due to concurrent update" if >> PostgreSQL runs in REPEATABLE READ or SERIALIZABLE level, and the >> session aborts. In order to achieve

Re: Retry in pgbench

2021-04-13 Thread Thomas Munro
On Tue, Apr 13, 2021 at 5:51 PM Tatsuo Ishii wrote: > Currently standard pgbench scenario produces transaction serialize > errors "could not serialize access due to concurrent update" if > PostgreSQL runs in REPEATABLE READ or SERIALIZABLE level, and the > session aborts. In order to achieve meani