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

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



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Enhanced error message to include hint messages for redundant options error
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Fix numeric_mul() overflow due to too many digits after decimal