Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors - Mailing list pgsql-hackers

From Yugo NAGATA
Subject Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Date
Msg-id 20210713155052.0cedced0ea5d8d3cd4166d9d@sraoss.co.jp
Whole thread Raw
In response to Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Responses Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors  (Yugo NAGATA <nagata@sraoss.co.jp>)
List pgsql-hackers
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>



pgsql-hackers by date:

Previous
From: gkokolatos@pm.me
Date:
Subject: Re: Introduce pg_receivewal gzip compression tests
Next
From: Peter Smith
Date:
Subject: Re: row filtering for logical replication