From: Yugo NAGATA <nagata@sraoss.co.jp>
To: Tatsuo Ishii <ishii@sraoss.co.jp>
Cc: coelho@cri.ensmp.fr
Cc: thomas.munro@gmail.com
Cc: m.polyakova@postgrespro.ru
Cc: alvherre@2ndquadrant.com
Cc: pgsql-hackers@postgresql.org
Cc: teodor@sigaev.ru
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Date: Tue, 13 Jul 2021 15:50:52 +0900
Message-ID: <20210713155052.0cedced0ea5d8d3cd4166d9d@sraoss.co.jp> (raw)
In-Reply-To: <20210713.143500.1975764363406618158.t-ishii@gmail.com>
References: <alpine.DEB.2.22.394.2107101914220.775110@pseudo>
<20210713.130049.878809075484022658.t-ishii@gmail.com>
<20210713133224.db0d27ca57f423c1ef329cdc@sraoss.co.jp>
<20210713.143500.1975764363406618158.t-ishii@gmail.com>
On Tue, 13 Jul 2021 14:35:00 +0900 (JST)
Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
> >> > I would tend to agree with this behavior, that is not to start any new
> >> > transaction or transaction attempt once -T has expired.
> >
> > That is the behavior in the latest patch. Once -T has expired, any new
> > transaction or retry does not start.
>
> Actually v14 has not changed the behavior in this regard as explained
> in different email:
Right. Both of v13 and v14 doen't start any new transaction or retry once
-T has expired.
> >> > I'm a little hesitant about how to count and report such unfinished
> >> > because of bench timeout transactions, though. Not counting them seems
> >> > to be the best option.
> >>
> >> I agree.
> >
> > I also agree. Although I couldn't get an answer what does he think the actual
> > harm for users due to termination of retrying by the -T option is, I guess it just
> > complained about reporting the termination of retrying as failures. Therefore,
> > I will fix to finish the benchmark when the time is over during retrying, that is,
> > change the state to CSTATE_FINISHED instead of CSTATE_ERROR in such cases.
>
> I guess Fabien wanted it differently. Suppose "-c 10 and -T 30" and we
> have 100 success transactions by time 25. At time 25 pgbench starts
> next benchmark cycle and by time 30 there are 10 failing transactions
> (because they are retrying). pgbench stops the execution at time
> 30. According your proposal (change the state to CSTATE_FINISHED
> instead of CSTATE_ERROR) the total number of success transactions will
> be 100 + 10 = 110, right?
No. The last failed transaction is not counted because CSTATE_END_TX is
bypassed, so please don't worry.
> Also actually I have explained the harm number of times but you have
> kept on ignoring it because "it's subtle". My request has been pretty
> simple.
>
> > number of failed transactions: 9 (0.916%)
>
> I don't like this and want to have the failed transactions to be 0.
> Who wants a benchmark result having errors?
I was asking you because I would like to confirm what you really complained
about; whether the problem is that retrying transaction is terminated by -T
option, or that pgbench reports it as the number of failed transactions? But
now, I understood this is the latter that you don't want to count the temination
of retrying as failures. Thanks.
Regards,
Yugo Nagata
--
Yugo NAGATA <nagata@sraoss.co.jp>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nagata@sraoss.co.jp, ishii@sraoss.co.jp, coelho@cri.ensmp.fr, thomas.munro@gmail.com, m.polyakova@postgrespro.ru, alvherre@2ndquadrant.com, teodor@sigaev.ru
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
In-Reply-To: <20210713155052.0cedced0ea5d8d3cd4166d9d@sraoss.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox