> 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
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
>
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
> 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 (
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
> 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
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
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 meaningful results even in these
transaction isolation levels, I w
