Make detach-partition-concurrently-3 less timing-sensitive
This recently added test has shown to be too sensitive to timing when
sending a cancel to a session waiting for a lock.
We fix this by running a no-op query in the blocked session immediately
after the cancel; this avoids the session that sent the cancel sending
another query immediately before the cancel has been reported.
Idea by Noah Misch.
With that fix, we sometimes see that the cancel error report is shown
only relative to the step that is cancelled, instead of together with
the step that sends the cancel. To increase the probability that both
steps are shown togeter, add a 0.1s sleep to the cancel. In normal
conditions this appears sufficient to silence most failures, but we'll
see that the slower buildfarm members say about it.
Reported-by: Takamichi Osumi <osumi.takamichi@fujitsu.com>
Discussion: https://postgr.es/m/OSBPR01MB4888C4ABA361C7E81094AC66ED269@OSBPR01MB4888.jpnprd01.prod.outlook.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/5e0b1aeb2dfed4f1eb7ac5154c1573885a70db41
Modified Files
--------------
.../expected/detach-partition-concurrently-3.out | 162 ++++++++++++---------
.../specs/detach-partition-concurrently-3.spec | 44 +++---
2 files changed, 115 insertions(+), 91 deletions(-)