On Mon, Oct 20, 2025 at 8:15 AM torikoshia <[email protected]> wrote: > > S1: Set an injection point to wait in HandleLogQueryPlanInterrupt > > [runs to completion]. > > S2: Take an advisory lock [runs to completion]. > > S1: Start a query that attempts to acquire the same advisory lock. > > Use $node->wait_for_event() to be sure that S1 is now waiting on the > > lock. > > S2: Commit, thus releasing the advisory lock [runs to completion]. > > Use $node->wait_for_event() to be sure that S1 is now waiting inside > > HandleLogQueryPlanInterrupt. > > Remember the log offset, as in > > src/test/modules/test_misc/t/005_timeouts.pl > > Detach the injection point. > > Use $node->wait_for_log() to wait for the expected log message to > > appear. > > > > It's really hard to make these kinds of sequences race-free, so there > > could well be bugs in the above outline, but I hope it is close to the > > right thing. > > Thanks for the detailed outline! > Attached patch adds a test following the suggestion.
Thanks. I'm not sure about this part: +# Run pg_log_query_plan(). +# Then commit the session 2 to release the advisory lock. +$psql_session2->query_safe( + qq[ + SELECT pg_log_query_plan($session1_pid); + COMMIT; +]); This does two relevant things: one is to send a signal (the SELECT) and the other is to release a lock (the COMMIT). Both of these events will soon be perceived by the other session, but I am not sure whether we have a guarantee about the order. If it's possible for the lock release to be observed by the target session before the log-query-plan interrupt arrives, the test will fail. If that is possible, I think we should try to find a way to plug the gap. If it's not possible, I think we should add a comment explaining why it can't happen. Also, my apologies for taking some time to return to this thread. Thanks, -- Robert Haas EDB: http://www.enterprisedb.com
