Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |
Дата | |
Msg-id | alpine.DEB.2.22.394.2107101914220.775110@pseudo обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors (Yugo NAGATA <nagata@sraoss.co.jp>) |
Ответы |
Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
|
Список | 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 по дате отправления: