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

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

I agree.

>> 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?

Right.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Amul Sul
Date:
Subject: Re: [CLOBBER_CACHE]Server crashed with segfault 11 while executing clusterdb
Next
From: "r.takahashi_2@fujitsu.com"
Date:
Subject: RE: Transactions involving multiple postgres foreign servers, take 2