Date: Tue, 13 Jul 2021 15:50:52 +0900
From: Yugo NAGATA <nagata@sraoss.co.jp>
To: Tatsuo Ishii <ishii@sraoss.co.jp>
Cc: coelho@cri.ensmp.fr, thomas.munro@gmail.com, m.polyakova@postgrespro.ru,
        alvherre@2ndquadrant.com, pgsql-hackers@postgresql.org,
        teodor@sigaev.ru
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Message-Id: <20210713155052.0cedced0ea5d8d3cd4166d9d@sraoss.co.jp>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20210713155052.0cedced0ea5d8d3cd4166d9d%40sraoss.co.jp>
Precedence: bulk

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>