blob: 62cdafda988510b2ecebafd9d34ed8f4062b1ed7 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
# INSERT...ON CONFLICT DO UPDATE test
#
# This test tries to expose problems with the interaction between concurrent
# sessions.
setup
{
CREATE TABLE upsert (key int primary key, val text);
}
teardown
{
DROP TABLE upsert;
}
session s1
setup
{
BEGIN ISOLATION LEVEL READ COMMITTED;
}
step insert1 { INSERT INTO upsert(key, val) VALUES(1, 'insert1') ON CONFLICT (key) DO UPDATE set val = upsert.val || ' updated by insert1'; }
step c1 { COMMIT; }
step a1 { ABORT; }
session s2
setup
{
BEGIN ISOLATION LEVEL READ COMMITTED;
}
step insert2 { INSERT INTO upsert(key, val) VALUES(1, 'insert2') ON CONFLICT (key) DO UPDATE set val = upsert.val || ' updated by insert2'; }
step select2 { SELECT * FROM upsert; }
step c2 { COMMIT; }
# One session (session 2) block-waits on another (session 1) to determine if it
# should proceed with an insert or update. Notably, this entails updating a
# tuple while there is no version of that tuple visible to the updating
# session's snapshot. This is permitted only in READ COMMITTED mode.
permutation insert1 insert2 c1 select2 c2
permutation insert1 insert2 a1 select2 c2
|
