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-10-20 12:15:03 |
Message-ID: | 5fbde7ee5e41cc2ad6012bf273a9539d@oss.nttdata.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-10-17 05:15, Robert Haas wrote:
> On Wed, Oct 1, 2025 at 5:11 AM torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
> wrote:
>> I was also considering using an isolation test and injection points,
>> like in the attached PoC patch. The main steps are:
>>
>> In session1, set an injection point to wait during query execution.
>> In session1, run a query that waits at the injection point.
>> In session2, call pg_log_query_plan().
>> In session2, wake up session1.
>
> The key thing here is that we need to verify that each thing we do in
> each session actually takes effect before doing the next thing. When
> we're running an SQL statement to completion, nothing special is
> needed: we just wait for completion -- but in any other case, we need
> some kind of an explicit wait step after performing the action.
That makes sense.
> Also,
> I don't think we need the standard-executor-run injection point you've
> introduced, because we have other ways to make query execution wait
> already, such as (a) pg_sleep() with a very long timeout or (b)
> pg_advisory_lock() on a lock held by another process. So I imagine the
> outline maybe looking something like this:
>
> 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.
--
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA Japan Corporation to SRA OSS K.K.
Attachment | Content-Type | Size |
---|---|---|
v50-0001-Add-function-to-log-the-plan-of-the-currently-ru.patch | text/x-diff | 38.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Matheus Alcantara | 2025-10-20 12:37:24 | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue |
Previous Message | Tom Lane | 2025-10-20 12:05:28 | Re: Question on ThrowErrorData |