On Thu, Aug 6, 2020 at 10:42 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Andy Fan <zhihui.fan1...@gmail.com> writes: > > On Thu, Aug 6, 2020 at 12:02 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> See my straw-man proposal downthread. > > > 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.. > > Ah, I was going to play arond with that today, but you beat me to it ;-) > > Very glad to be helpful.
> A few thoughts after a quick look at the patch: > > * I had envisioned that there's a custom GUC controlling the lock ID > used; this would allow blocking different sessions at different points, > if we ever need that. Also, I'd make the GUC start out as zero which > means "do nothing", so that merely loading the module has no immediate > effect. > > I forgot to say I didn't get the point of the guc variable in the last thread, now I think it is a smart idea, so added it. In this way, one session can only be blocked at one place, it may not be an issue in practise. * Don't really see the point of the before-planning lock. > > yes.. it was removed now. * Rather than exposing internal declarations from lockfuncs.c, you > could just write calls to pg_advisory_lock_int8 etc. using > DirectFunctionCall1. > > Thanks for sharing it, this method looks pretty good. > * We need some better name than "test_module". I had vaguely thought > about "delay_execution", but am surely open to better ideas. > > Both names look good to me, delay_execution looks better, it is used in v2. Attached is the v2 patch. -- Best Regards Andy Fan
v2-0001-delay_execution-used-for-concurrency-case-simulat.patch
Description: Binary data
