You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use annotations to reduce instability of isolation-test results.
We've long contended with isolation test results that aren't entirely
stable. Some test scripts insert long delays to try to force stable
results, which is not terribly desirable; but other erratic failure
modes remain, causing unrepeatable buildfarm failures. I've spent a
fair amount of time trying to solve this by improving the server-side
support code, without much success: that way is fundamentally unable
to cope with diffs that stem from chance ordering of arrival of
messages from different server processes.
We can improve matters on the client side, however, by annotating
the test scripts themselves to show the desired reporting order
of events that might occur in different orders. This patch adds
three types of annotations to deal with (a) test steps that might or
might not complete their waits before the isolationtester can see them
waiting; (b) test steps in different sessions that can legitimately
complete in either order; and (c) NOTIFY messages that might arrive
before or after the completion of a step in another session. We might
need more annotation types later, but this seems to be enough to deal
with the instabilities we've seen in the buildfarm. It also lets us
get rid of all the long delays that were previously used, cutting more
than a minute off the runtime of the isolation tests.
Back-patch to all supported branches, because the buildfarm
instabilities affect all the branches, and because it seems desirable
to keep isolationtester's capabilities the same across all branches
to simplify possible future back-patching of tests.
Discussion: https://postgr.es/m/327948.1623725828@sss.pgh.pa.us
Copy file name to clipboardExpand all lines: src/test/isolation/expected/eval-plan-qual.out
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -551,7 +551,7 @@ balance
551
551
step updwctefail: WITH doup AS (UPDATE accounts SET balance = balance + 1100 WHERE accountid = 'checking' RETURNING *, update_checking(999)) UPDATE accounts a SET balance = doup.balance + 100 FROM doup RETURNING *; <waiting ...>
552
552
step c1: COMMIT;
553
553
step updwctefail: <... completed>
554
-
error in steps c1 updwctefail: ERROR: tuple to be updated was already modified by an operation triggered by the current command
554
+
ERROR: tuple to be updated was already modified by an operation triggered by the current command
555
555
step c2: COMMIT;
556
556
step read: SELECT * FROM accounts ORDER BY accountid;
557
557
accountid balance
@@ -584,7 +584,7 @@ balance
584
584
step delwctefail: WITH doup AS (UPDATE accounts SET balance = balance + 1100 WHERE accountid = 'checking' RETURNING *, update_checking(999)) DELETE FROM accounts a USING doup RETURNING *; <waiting ...>
585
585
step c1: COMMIT;
586
586
step delwctefail: <... completed>
587
-
error in steps c1 delwctefail: ERROR: tuple to be deleted was already modified by an operation triggered by the current command
587
+
ERROR: tuple to be deleted was already modified by an operation triggered by the current command
588
588
step c2: COMMIT;
589
589
step read: SELECT * FROM accounts ORDER BY accountid;
0 commit comments