| From: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Atsushi Torikoshi <torikoshia(dot)tech(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, samimseih(at)gmail(dot)com, destrex271(at)gmail(dot)com |
| Subject: | Re: RFC: Logging plan of the running query |
| Date: | 2025-11-20 01:52:25 |
| Message-ID: | 9ce54f35e3802ad53156b926670f5880@oss.nttdata.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2025-11-20 02:23, Robert Haas wrote:
> On Mon, Oct 20, 2025 at 8:15 AM torikoshia <torikoshia(at)oss(dot)nttdata(dot)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.
| Attachment | Content-Type | Size |
|---|---|---|
| v51-0001-Add-function-to-log-the-plan-of-the-currently-ru.patch | text/x-diff | 38.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2025-11-20 01:55:16 | Re: Skipping schema changes in publication |
| Previous Message | Neil Chen | 2025-11-20 01:49:51 | Re: Use strtoi64() in pgbench, replacing its open-coded implementation |