postgresql/src/test/isolation/expected/lock-update-delete_1.out

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

274 lines
6.5 KiB
Plaintext
Raw Normal View History

Parsed test spec with 2 sessions
starting permutation: s2b s1l s2u s2_blocker1 s2_unlock s2c
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker1: DELETE FROM foo;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s2c: COMMIT;
step s1l: <... completed>
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
ERROR: could not serialize access due to concurrent update
starting permutation: s2b s1l s2u s2_blocker2 s2_unlock s2c
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker2: UPDATE foo SET key = 2 WHERE key = 1;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s2c: COMMIT;
step s1l: <... completed>
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
ERROR: could not serialize access due to concurrent update
starting permutation: s2b s1l s2u s2_blocker3 s2_unlock s2c
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker3: UPDATE foo SET value = 2 WHERE key = 1;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s1l: <... completed>
key|value
---+-----
1| 1
(1 row)
step s2c: COMMIT;
starting permutation: s2b s1l s2u s2_blocker1 s2_unlock s2r
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker1: DELETE FROM foo;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s2r: ROLLBACK;
step s1l: <... completed>
key|value
---+-----
1| 1
(1 row)
starting permutation: s2b s1l s2u s2_blocker2 s2_unlock s2r
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker2: UPDATE foo SET key = 2 WHERE key = 1;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s2r: ROLLBACK;
step s1l: <... completed>
key|value
---+-----
1| 1
(1 row)
starting permutation: s2b s1l s2u s2_blocker3 s2_unlock s2r
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker3: UPDATE foo SET value = 2 WHERE key = 1;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s1l: <... completed>
key|value
---+-----
1| 1
(1 row)
step s2r: ROLLBACK;
starting permutation: s2b s1l s2u s2_blocker1 s2c s2_unlock
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker1: DELETE FROM foo;
step s2c: COMMIT;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s1l: <... completed>
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
ERROR: could not serialize access due to concurrent update
starting permutation: s2b s1l s2u s2_blocker2 s2c s2_unlock
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker2: UPDATE foo SET key = 2 WHERE key = 1;
step s2c: COMMIT;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s1l: <... completed>
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
ERROR: could not serialize access due to concurrent update
starting permutation: s2b s1l s2u s2_blocker3 s2c s2_unlock
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker3: UPDATE foo SET value = 2 WHERE key = 1;
step s2c: COMMIT;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s1l: <... completed>
key|value
---+-----
1| 1
(1 row)
starting permutation: s2b s1l s2u s2_blocker1 s2r s2_unlock
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker1: DELETE FROM foo;
step s2r: ROLLBACK;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s1l: <... completed>
key|value
---+-----
1| 1
(1 row)
starting permutation: s2b s1l s2u s2_blocker2 s2r s2_unlock
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker2: UPDATE foo SET key = 2 WHERE key = 1;
step s2r: ROLLBACK;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s1l: <... completed>
key|value
---+-----
1| 1
(1 row)
starting permutation: s2b s1l s2u s2_blocker3 s2r s2_unlock
pg_advisory_lock
----------------
(1 row)
step s2b: BEGIN;
step s1l: SELECT * FROM foo WHERE pg_advisory_xact_lock(0) IS NOT NULL AND key = 1 FOR KEY SHARE; <waiting ...>
step s2u: UPDATE foo SET value = 2 WHERE key = 1;
step s2_blocker3: UPDATE foo SET value = 2 WHERE key = 1;
step s2r: ROLLBACK;
step s2_unlock: SELECT pg_advisory_unlock(0);
pg_advisory_unlock
------------------
t
(1 row)
step s1l: <... completed>
key|value
---+-----
1| 1
(1 row)