Date: Sat, 10 Jul 2021 19:19:45 +0200 (CEST)
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Yugo NAGATA <nagata@sraoss.co.jp>
cc: Tatsuo Ishii <ishii@sraoss.co.jp>, 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
In-Reply-To: <20210707224642.4e8265865fda4e118c4de5ee@sraoss.co.jp>
Message-ID: <alpine.DEB.2.22.394.2107101914220.775110@pseudo>
References: <20210706164624.dd22be9e4f10ed2657d25552@sraoss.co.jp>
 <20210707.161123.574070522694073225.t-ishii@gmail.com>
 <20210707195323.02f64ddf51c77ce2ca41e465@sraoss.co.jp>
 <20210707.215016.2091144688016450280.t-ishii@gmail.com>
 <20210707224642.4e8265865fda4e118c4de5ee@sraoss.co.jp>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
 <https://www.postgresql.org/message-id/alpine.DEB.2.22.394.2107101914220.775110%40pseudo>
Precedence: bulk


Hello,

> Of course, users themselves should be careful of problematic script, but it
> would be better that pgbench itself avoids problems if pgbench can beforehand.
>
>> Or, we should terminate the last cycle of benchmark regardless it is
>> retrying or not if -T expires. This will make pgbench behaves much
>> more consistent.

I would tend to agree with this behavior, that is not to start any new 
transaction or transaction attempt 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.

> Hmmm, indeed this might make the behaviour a bit consistent, but I am not
> sure such behavioural change benefit users.

The user benefit would be that if they asked for a 100s benchmark, pgbench 
does a reasonable effort not to overshot that?

-- 
Fabien.