On Mon, Nov 2, 2026 at 8:20 PM Hayato Kuroda (Fujitsu) <[email protected]> wrote: > > Hi Sawada-san, > > > The 0001 patch basically looks good to me. Is there any reason that > > the patch sets "verbose => 0" to some query_safe() calls? Also, I'd > > suggest renaming the support function to quit_and_wait(). > > I just tried to suppress output, not mandatory. PSA fixed version. > I fixed 0001 as well.
Thank you for updating the patch! I pushed 0001 and 0002. > > I'll review the 0003 patch soon. IIUC the problem that the 0003 patch tries to fix is somewhat different from the problem that the 0001 patch fixed. The former is that a backend's exit cleanup can detach an injection point that is attached by another backend, whereas the latter is that attaching an injection point can fail with "already defined" error if the backend behind a background psql session is slow to exit for some reason. Regarding the former issue, I think it's okay that an injection point is detached by someone other than the one who attached it, since injection_points_detach() takes the name of the point and injection point names are global across backends. The problem is that injection points are also detached at process exit cleanup time, and it could detach the point even if it was attached by someone else. So if another backend attaches the same injection point in between, the exiting process blindly detaches it even though it didn't attach that point. In tests with injection points, it's conventional to do injection_points_detach() and injection_points_wakeup(), and continue the next test. I think it would not be great for us to have to take care of this race condition every time we write a test. I guess it would be better to fix the injection point side so that detaching points during process exit cleanup affects only the points attached by itself. I think it's already a separate topic from the issue reported in this thread, so I'd suggest starting a new thread for this problem. We can decide whether we need the 0003 patch based on the discussion there. Fortunately, the problem in 010_index_concurrently_upsert.pl hasn't happened on buildfarm yet, so we would have some time to discuss the right approach for this issue. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
