| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
| Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, thomas(dot)munro(at)gmail(dot)com, m(dot)polyakova(at)postgrespro(dot)ru, alvherre(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, teodor(at)sigaev(dot)ru |
| Subject: | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |
| Date: | 2021-07-10 17:19:45 |
| Message-ID: | alpine.DEB.2.22.394.2107101914220.775110@pseudo |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-07-10 17:30:42 | Re: pgsql: Fix numeric_mul() overflow due to too many digits after decimal |
| Previous Message | vignesh C | 2021-07-10 17:08:53 | Re: Enhanced error message to include hint messages for redundant options error |