On 2025-11-20 22:17, Robert Haas wrote:
On Wed, Nov 19, 2025 at 8:52 PM torikoshia <[email protected]>
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.
I have the same understanding.
A couple of testing suggestions, if you haven't already:
Thank you for the suggestions.
1. Run the test in a loop, say 100 times, to check for random failures.
I ran 010_pg_log_query_plan.pl 300 times, but it never failed.
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 inserted sleep(10) at each line in turn and ran the test 10 times for
each location, but fortunately (or unfortunately?) I did not observe any
failures.
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.
BTW to test not 010_pg_log_query_plan but pg_log_query_plan(), I also
invoked pg_log_query_plan() in 3 parallel sessions at 0.1-second
intervals(\watch 0.1) during running `make intallcheck` 10 times, and I
did not see any crashes.
--
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA Japan Corporation to SRA OSS K.K.
