On Thu, Aug 6, 2020 at 12:02 PM Tom Lane <t...@sss.pgh.pa.us> wrote:

> Andy Fan <zhihui.fan1...@gmail.com> writes:
> > On Thu, Aug 6, 2020 at 2:22 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> In the longer term, it's annoying that we have no test methodology
> >> for this other than "manually set a breakpoint here".
>
> > One of the methods I see is we can just add some GUC variable for some
> > action injection.   basically it adds some code based on the GUC like
> this;
>
> See my straw-man proposal downthread.  I'm not very excited about putting
> things like this into the standard build, because it's really hard to be
> sure that there are no security-hazard-ish downsides of putting in ways to
> get at testing behaviors from standard SQL.  And then there's the question
> of whether you're adding noticeable overhead to production builds.  So a
> loadable module that can use some existing hook to provide the needed
> behavior seems like a better plan to me, whenever we can do it that way.
>
> In general, though, it seems like we've seldom regretted investments in
> test tooling.
>
>                         regards, tom lane
>


Thanks for your explanation, I checked it again and it looks a very clean
method.  The attached is a draft patch based on my understanding.  Hope
I didn't  misunderstand you..

-- 
Best Regards
Andy Fan

Attachment: v1-0001-test_module-used-for-concurrency-case-simulation.patch
Description: Binary data

Reply via email to