Make detach-partition-concurrently-3 less timing-sensitive
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Tue, 25 May 2021 16:53:29 +0000 (12:53 -0400)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Tue, 25 May 2021 16:53:57 +0000 (12:53 -0400)
commit5e0b1aeb2dfed4f1eb7ac5154c1573885a70db41
tree34bba16e11e7f56a2c8a1fa2e8c7688d4a640aa7
parent8673a37c85fef00dd5b9c04197538142bec10542
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
src/test/isolation/expected/detach-partition-concurrently-3.out
src/test/isolation/specs/detach-partition-concurrently-3.spec