postgresql/src/test/isolation/specs/tuplelock-update.spec

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

38 lines
1.3 KiB
RPMSpec
Raw Normal View History

setup {
DROP TABLE IF EXISTS pktab;
CREATE TABLE pktab (id int PRIMARY KEY, data SERIAL NOT NULL);
INSERT INTO pktab VALUES (1, DEFAULT);
}
teardown {
DROP TABLE pktab;
}
session s1
step s1_advlock {
SELECT pg_advisory_lock(142857),
pg_advisory_lock(285714),
pg_advisory_lock(571428);
}
step s1_chain { UPDATE pktab SET data = DEFAULT; }
step s1_begin { BEGIN; }
step s1_grablock { SELECT * FROM pktab FOR KEY SHARE; }
step s1_advunlock1 { SELECT pg_advisory_unlock(142857); }
step s1_advunlock2 { SELECT pg_advisory_unlock(285714); }
step s1_advunlock3 { SELECT pg_advisory_unlock(571428); }
step s1_commit { COMMIT; }
session s2
step s2_update { UPDATE pktab SET data = DEFAULT WHERE pg_advisory_lock_shared(142857) IS NOT NULL; }
session s3
step s3_update { UPDATE pktab SET data = DEFAULT WHERE pg_advisory_lock_shared(285714) IS NOT NULL; }
session s4
step s4_update { UPDATE pktab SET data = DEFAULT WHERE pg_advisory_lock_shared(571428) IS NOT NULL; }
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
2021-06-23 03:43:12 +02:00
# We use blocker annotations on the s1_advunlockN steps so that we will not
# move on to the next step until the other session's released step finishes.
# This ensures stable ordering of the test output.
permutation s1_advlock s2_update s3_update s4_update s1_chain s1_begin s1_grablock s1_advunlock1(s2_update) s1_advunlock2(s3_update) s1_advunlock3(s4_update) s1_commit