Re: RFC: Logging plan of the running query
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: torikoshia <torikoshia@oss.nttdata.com>
Cc: Atsushi Torikoshi <torikoshia.tech@gmail.com>,
pgsql-hackers@lists.postgresql.org, samimseih@gmail.com, destrex271@gmail.com
Date: 2025-11-20T13:17:58Z
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
On Wed, Nov 19, 2025 at 8:52 PM torikoshia <torikoshia@oss.nttdata.com> wrote:
> 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.
Thanks, that looks better to me. Looking at this version, I wondered
whether this was OK:
+# Commit the session 2 to release the advisory lock.
+$psql_session2->query_safe("COMMIT;");
+
+my $log_offset = -s $node->logfile;
If the COMMIT causes something to appear in the log, we're not
guaranteed as to whether that will happen before or after we record
the log offset. However, the string for which we're looking will (if I
understand correctly) only appear after the wakeup/detach from the
injection point, so I don't think there's any real problem here.
A couple of testing suggestions, if you haven't already:
1. Run the test in a loop, say 100 times, to check for random failures.
2. Insert a sleep(10) after each line of the strict in turn and run it
(perhaps a few tiimes) and check to make sure that the tests still
pass. (I don't mean put sleep(10) after every line -- I mean put a
sleep(10) in one place at a time and keep moving it after you've
verified that the current location doesn't cause a failure.)
I know from experience that it's quite hard to get these tests to be
fully reliable and I won't feel too bad if it turns out we missed
something, but at least we can try.
--
Robert Haas
EDB: http://www.enterprisedb.com