Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Commit d03130d

Browse filesBrowse files
tglsfdctglsfdc
committed
Still further tweaking of deadlock isolation tests.
It turns out that there is a second race condition in the new deadlock-hard test: once the deadlock detector fires, it's uncertain whether step s7a8 or step s8a1 will report first, because killing s8's transaction unblocks s7. So far, s7 has only been seen to report first in CLOBBER_CACHE_ALWAYS builds, but it's pretty reproducible there, and in theory it should sometimes occur in normal builds too. If s7 were a bit slower than usual, that could also break the test, since the existing expected-file assumes that we'll see s7a8 report the first time we check it after s8a1 completes. To fix, add a post-lock delay to s7a8.
1 parent 9c9782f commit d03130d
Copy full SHA for d03130d

File tree

Expand file treeCollapse file tree

2 files changed

+10
-5
lines changed
Filter options
Expand file treeCollapse file tree

2 files changed

+10
-5
lines changed

‎src/test/isolation/expected/deadlock-hard.out

Copy file name to clipboardExpand all lines: src/test/isolation/expected/deadlock-hard.out
+6-3Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -15,12 +15,15 @@ step s3a4: LOCK TABLE a4; <waiting ...>
1515
step s4a5: LOCK TABLE a5; <waiting ...>
1616
step s5a6: LOCK TABLE a6; <waiting ...>
1717
step s6a7: LOCK TABLE a7; <waiting ...>
18-
step s7a8: LOCK TABLE a8; <waiting ...>
18+
step s7a8: LOCK TABLE a8; SELECT pg_sleep(5); <waiting ...>
1919
step s8a1: LOCK TABLE a1; <waiting ...>
2020
step s8a1: <... completed>
21-
step s7a8: <... completed>
22-
error in steps s8a1 s7a8: ERROR: deadlock detected
21+
ERROR: deadlock detected
2322
step s8c: COMMIT;
23+
step s7a8: <... completed>
24+
pg_sleep
25+
26+
2427
step s7c: COMMIT;
2528
step s6a7: <... completed>
2629
step s6c: COMMIT;

‎src/test/isolation/specs/deadlock-hard.spec

Copy file name to clipboardExpand all lines: src/test/isolation/specs/deadlock-hard.spec
+4-2Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,9 @@
11
# This is a straightforward deadlock scenario. Since it involves more than
22
# two processes, the main lock detector will find the problem and rollback
33
# the session that first discovers it. Set deadlock_timeout in each session
4-
# so that it's predictable which session fails.
4+
# so that it's predictable which session fails. Also, when s8 fails and
5+
# rolls back, it unblocks s7, so that there is a race as to whether s7a8
6+
# or s8a1 will report first. Add a delay in s7a8 to make that predictable.
57

68
setup
79
{
@@ -59,7 +61,7 @@ step "s6c" { COMMIT; }
5961
session "s7"
6062
setup { BEGIN; SET deadlock_timeout = '100s'; }
6163
step "s7a7" { LOCK TABLE a7; }
62-
step "s7a8" { LOCK TABLE a8; }
64+
step "s7a8" { LOCK TABLE a8; SELECT pg_sleep(5); }
6365
step "s7c" { COMMIT; }
6466

6567
session "s8"

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.