On Wed, Feb 05, 2025 at 11:03:25AM +0000, Bertrand Drouvot wrote: > I think that makes sense and the patch LGTM. > A few tests are already using this technique (including injection_points in > inplace.spec).
Well, that's not the end of the story, I have brushed the CF bot for some activity and noticed this one: https://cirrus-ci.com/task/6565511640645632 That's kind of rather hard to reach, it seems, but I also got it in one of my own runs: --- /tmp/cirrus-ci-build/src/test/modules/injection_points/expected/basic.out 2025-02-06 23:53:40.838077000 +0000 +++ /tmp/cirrus-ci-build/build/testrun/injection_points/isolation/results/basic.out 2025-02-06 23:56:21.848507000 +0000 @@ -13,13 +13,14 @@ (1 row) +step detach2: SELECT injection_points_detach('injection-points-wait'); <waiting ...> step wait1: <... completed> injection_points_run -------------------- (1 row) -step detach2: SELECT injection_points_detach('injection-points-wait'); +step detach2: <... completed> injection_points_detach ----------------------- This is telling us that the detach step could be seen as waiting by the isolation tester before the wait phase reports for completion. I didn't think it would be possible to get that, but well, we do. A marker like detach2(wait1) is not enough to cover that, as this ensures the order of the step completion output. Using detach2(*) which would cause the detach2 step to show as <waiting> immediately is not good either, as the wait could always complete between the detach's <waiting> and <completed>. There is an stronger trick mentioned at the end of the README that should be able to solve this new problem as well as the original one: an empty step between the wait and the detach. If we do that, the detach will never be launched until the wait has fully completed, bringing a stronger ordering of the events: we should never see the detach as waiting like in this new problem, now would we see the first problem where the wait would report its result after the detach. I have done a total of 10 runs in the CI with the attached, without getting a failure. HEAD was failing a bit more easily than that, with at least one failure every 5 runs in my branches. Will go adjust that in a bit as per the attached. -- Michael
From 8f7d244eddd965c4e4725cc88257292ee65214d2 Mon Sep 17 00:00:00 2001
From: Michael Paquier <mich...@paquier.xyz>
Date: Fri, 7 Feb 2025 13:36:40 +0900
Subject: [PATCH] Extra tweak for injection test permutation
---
src/test/modules/injection_points/expected/basic.out | 3 ++-
src/test/modules/injection_points/specs/basic.spec | 7 ++++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/test/modules/injection_points/expected/basic.out b/src/test/modules/injection_points/expected/basic.out
index 840ce2dac90..4fc218ed00d 100644
--- a/src/test/modules/injection_points/expected/basic.out
+++ b/src/test/modules/injection_points/expected/basic.out
@@ -1,6 +1,6 @@
Parsed test spec with 2 sessions
-starting permutation: wait1 wakeup2 detach2
+starting permutation: wait1 wakeup2 noop1 detach2
injection_points_attach
-----------------------
@@ -19,6 +19,7 @@ injection_points_run
(1 row)
+step noop1:
step detach2: SELECT injection_points_detach('injection-points-wait');
injection_points_detach
-----------------------
diff --git a/src/test/modules/injection_points/specs/basic.spec b/src/test/modules/injection_points/specs/basic.spec
index 753128e7f36..13d2793f6e4 100644
--- a/src/test/modules/injection_points/specs/basic.spec
+++ b/src/test/modules/injection_points/specs/basic.spec
@@ -20,6 +20,7 @@ setup {
SELECT injection_points_attach('injection-points-wait', 'wait');
}
step wait1 { SELECT injection_points_run('injection-points-wait'); }
+step noop1 { }
session s2
step wakeup2 { SELECT injection_points_wakeup('injection-points-wait'); }
@@ -27,9 +28,9 @@ step detach2 { SELECT injection_points_detach('injection-points-wait'); }
# Detach after wait and wakeup. Note that the detach may finish before
# the SQL function doing the wait returns its result. In order to avoid
-# any ordering issues, the detach step reports its result only once the
-# wait has completed. This is enforced with a parenthesized marker.
-permutation wait1 wakeup2 detach2(wait1)
+# any ordering issues, a no-op step is added after the wait, so as the
+# detach is not launched until the wait has completed.
+permutation wait1 wakeup2 noop1 detach2
# Detach before wakeup. s1 waits until wakeup, ignores the detach.
permutation wait1 detach2 wakeup2
--
2.47.2
signature.asc
Description: PGP signature
