Re: RFC: Logging plan of the running query
| От | torikoshia |
|---|---|
| Тема | Re: RFC: Logging plan of the running query |
| Дата | |
| Msg-id | 9ce54f35e3802ad53156b926670f5880@oss.nttdata.com обсуждение исходный текст |
| Ответ на | Re: RFC: Logging plan of the running query (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: RFC: Logging plan of the running query
|
| Список | pgsql-hackers |
On 2025-11-20 02:23, Robert Haas wrote: > On Mon, Oct 20, 2025 at 8:15 AM torikoshia <torikoshia@oss.nttdata.com> > 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. I think it's possible. Updated the test so that COMMIT happens only after we confirm that the backend is already waiting at the injection point. > Also, my apologies for taking some time to return to this thread. Not at all -- I really appreciate your continued review. -- Regards, -- Atsushi Torikoshi Seconded from NTT DATA Japan Corporation to SRA OSS K.K.
Вложения
В списке pgsql-hackers по дате отправления: