Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
От | Yugo NAGATA |
---|---|
Тема | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors |
Дата | |
Msg-id | 20220320032321.5a38d9e25ffa8650360b0549@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
|
Список | pgsql-hackers |
Hello Fabien, On Sat, 12 Mar 2022 15:54:54 +0100 (CET) Fabien COELHO <coelho@cri.ensmp.fr> wrote: > Hello Yugo-san, > > About Pgbench error handling v16: Thank you for your review! I attached the updated patches. > This patch set needs a minor rebase because of 506035b0. Otherwise, patch > compiles, global and local "make check" are ok. Doc generation is ok. I rebased it. > ## About v16-2 > English: "he will be aborted" -> "it will be aborted". Fixed. > I'm still not sure I like the "failure detailed" option, ISTM that the report > could be always detailed. That would remove some complexity and I do not think > that people executing a bench with error handling would mind having the details. > No big deal. I didn't change it because I think those who don't expect any failures using a well designed script may not need details of failures. I think reporting such details will be required only for benchmarks where any failures are expected. > printVerboseErrorMessages: I'd make the buffer static and initialized only once > so that there is no significant malloc/free cycle involved when calling the function. OK. I fixed printVerboseErrorMessages to use a static variable. > advanceConnectionState: I'd really prefer not to add new variables (res, status) > in the loop scope, and only declare them when actually needed in the state branches, > so as to avoid any unwanted interaction between states. I fixed to declare the variables in the case statement blocks. > typo: "fullowing" -> "following" fixed. > Pipeline cleaning: the advance function is already soooo long, I'd put that in a > separate function and call it. Ok. I made a new function "discardUntilSync" for the pipeline cleaning. > I think that the report should not remove data when they are 0, otherwise it makes > it harder to script around it (in failures_detailed on line 6284). I fixed to report both serialization and deadlock failures always even when they are 0. Regards, Yugo Nagata -- Yugo NAGATA <nagata@sraoss.co.jp>
Вложения
В списке pgsql-hackers по дате отправления: