|From:||Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>|
|To:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Sat, 12 Mar 2022 15:54:54 +0100 (CET)
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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".
> 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"
> 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.
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
|Next Message||Robert Haas||2022-03-19 18:33:10||Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints|
|Previous Message||Andres Freund||2022-03-19 18:16:48||Re: Regression tests failures on Windows Server 2019 - on master at commit # d816f366b|