Re: RFC: Logging plan of the running query
torikoshia <torikoshia@oss.nttdata.com>
From: torikoshia <torikoshia@oss.nttdata.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Atsushi Torikoshi <torikoshia.tech@gmail.com>,
pgsql-hackers@lists.postgresql.org, samimseih@gmail.com,
destrex271@gmail.com
Date: 2025-10-20T12:15:03Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
ecpg: Catch zero-length Unicode identifiers correctly
- a18b6d2dc288 15.0 cited
-
Improve warning message in pg_signal_backend()
- 7fa945b857cc 15.0 cited
-
Add assert to ensure that page locks don't participate in deadlock cycle.
- 72e78d831ab5 13.0 cited
Attachments
- v50-0001-Add-function-to-log-the-plan-of-the-currently-ru.patch (text/x-diff) patch v50-0001
On 2025-10-17 05:15, Robert Haas wrote: > On Wed, Oct 1, 2025 at 5:11 AM torikoshia <torikoshia@oss.nttdata.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.