Reduce length of GIN predicate locking isolation test suite

Isolation test suite of GIN predicate locking was criticized for being too slow,
especially under Valgrind.  This commit is intended to accelerate it.  Tests are
simplified in the following ways.

  1) Amount of data is reduced.  We're now close to the minimal amount of data,
     which produces at least one posting tree and at least two pages of entry
     tree.
  2) Three isolation tests are merged into one.
  3) Only one tuple is queried from posting tree.  So, locking of index is the
     same, but tuple locks are not propagated to relation lock.  Also, it is
     faster.
  4) Test cases itself are simplified.  Now each test case run just one INSERT
     and one SELECT involving GIN, which either conflict or not.

Discussion: https://postgr.es/m/20181204000740.ok2q53nvkftwu43a%40alap3.anarazel.de
Reported-by: Andres Freund
Tested-by: Andrew Dunstan
Author: Alexander Korotkov
Backpatch-through: 11
This commit is contained in:
Alexander Korotkov 2018-12-28 03:33:10 +03:00
parent fd7c081955
commit fcdda202bc
7 changed files with 508 additions and 956 deletions

View File

@ -1,30 +0,0 @@
Parsed test spec with 3 sessions
starting permutation: r1 r2 w1 c1 w2 c2
step r1: SELECT count(*) FROM gin_tbl WHERE p @> array[1000];
count
2
step r2: SELECT * FROM other_tbl;
id
step w1: INSERT INTO other_tbl VALUES (42);
step c1: COMMIT;
step w2: INSERT INTO gin_tbl SELECT array[1000,19001];
ERROR: could not serialize access due to read/write dependencies among transactions
step c2: COMMIT;
starting permutation: r1 r2 w1 c1 fastupdate_on w2 c2
step r1: SELECT count(*) FROM gin_tbl WHERE p @> array[1000];
count
2
step r2: SELECT * FROM other_tbl;
id
step w1: INSERT INTO other_tbl VALUES (42);
step c1: COMMIT;
step fastupdate_on: ALTER INDEX ginidx SET (fastupdate = on);
step w2: INSERT INTO gin_tbl SELECT array[1000,19001];
ERROR: could not serialize access due to read/write dependencies among transactions
step c2: COMMIT;

View File

@ -1,15 +0,0 @@
Parsed test spec with 2 sessions
starting permutation: r1 r2 w1 c1 w2 c2
step r1: SELECT count(*) FROM gin_tbl WHERE p @> array[-1];
count
0
step r2: SELECT * FROM other_tbl;
id
step w1: INSERT INTO other_tbl VALUES (42);
step c1: COMMIT;
step w2: INSERT INTO gin_tbl SELECT array[-1];
ERROR: could not serialize access due to read/write dependencies among transactions
step c2: COMMIT;

File diff suppressed because it is too large Load Diff

View File

@ -70,8 +70,6 @@ test: vacuum-concurrent-drop
test: predicate-hash
test: predicate-gist
test: predicate-gin
test: predicate-gin-fastupdate
test: predicate-gin-nomatch
test: partition-key-update-1
test: partition-key-update-2
test: partition-key-update-3

View File

@ -1,49 +0,0 @@
#
# Test that predicate locking on a GIN index works correctly, even if
# fastupdate is turned on concurrently.
#
# 0. fastupdate is off
# 1. Session 's1' acquires predicate lock on page X
# 2. fastupdate is turned on
# 3. Session 's2' inserts a new tuple to the pending list
#
# This test tests that if the lock acquired in step 1 would conflict with
# the scan in step 1, we detect that conflict correctly, even if fastupdate
# was turned on in-between.
#
setup
{
create table gin_tbl(p int4[]);
insert into gin_tbl select array[g, g*2,g*3] from generate_series(1, 10000) g;
insert into gin_tbl select array[4,5,6] from generate_series(10001, 20000) g;
create index ginidx on gin_tbl using gin(p) with (fastupdate = off);
create table other_tbl (id int4);
}
teardown
{
drop table gin_tbl;
drop table other_tbl;
}
session "s1"
setup { BEGIN ISOLATION LEVEL SERIALIZABLE; SET enable_seqscan=off; }
step "r1" { SELECT count(*) FROM gin_tbl WHERE p @> array[1000]; }
step "w1" { INSERT INTO other_tbl VALUES (42); }
step "c1" { COMMIT; }
session "s2"
setup { BEGIN ISOLATION LEVEL SERIALIZABLE; SET enable_seqscan=off; }
step "r2" { SELECT * FROM other_tbl; }
step "w2" { INSERT INTO gin_tbl SELECT array[1000,19001]; }
step "c2" { COMMIT; }
session "s3"
step "fastupdate_on" { ALTER INDEX ginidx SET (fastupdate = on); }
# This correctly throws serialization failure.
permutation "r1" "r2" "w1" "c1" "w2" "c2"
# But if fastupdate is turned on in the middle, we miss it.
permutation "r1" "r2" "w1" "c1" "fastupdate_on" "w2" "c2"

View File

@ -1,35 +0,0 @@
#
# Check that GIN index grabs an appropriate lock, even if there is no match.
#
setup
{
create table gin_tbl(p int4[]);
insert into gin_tbl select array[g, g*2,g*3] from generate_series(1, 10000) g;
insert into gin_tbl select array[4,5,6] from generate_series(10001, 20000) g;
create index ginidx on gin_tbl using gin(p) with (fastupdate = off);
create table other_tbl (id int4);
}
teardown
{
drop table gin_tbl;
drop table other_tbl;
}
session "s1"
setup { BEGIN ISOLATION LEVEL SERIALIZABLE; SET enable_seqscan=off; }
# Scan with no match.
step "r1" { SELECT count(*) FROM gin_tbl WHERE p @> array[-1]; }
step "w1" { INSERT INTO other_tbl VALUES (42); }
step "c1" { COMMIT; }
session "s2"
setup { BEGIN ISOLATION LEVEL SERIALIZABLE; SET enable_seqscan=off; }
step "r2" { SELECT * FROM other_tbl; }
# Insert row that would've matched in step "r1"
step "w2" { INSERT INTO gin_tbl SELECT array[-1]; }
step "c2" { COMMIT; }
# This should throw serialization failure.
permutation "r1" "r2" "w1" "c1" "w2" "c2"

View File

@ -11,15 +11,17 @@
setup
{
create table gin_tbl(id int4, p int4[]);
insert into gin_tbl select g, array[g, g*2,g*3] from generate_series(1, 10000) g;
insert into gin_tbl select g, array[4,5,6] from generate_series(10001, 20000) g;
create table gin_tbl(p int4[]);
insert into gin_tbl select array[1] from generate_series(1, 8192) g;
insert into gin_tbl select array[g] from generate_series(2, 800) g;
create index ginidx on gin_tbl using gin(p) with (fastupdate = off);
create table other_tbl(v int4);
}
teardown
{
drop table gin_tbl;
drop table other_tbl;
}
session "s1"
@ -29,19 +31,13 @@ setup
set enable_seqscan=off;
}
# enable pending list for a small subset of tests
step "fu1" { alter index ginidx set (fastupdate = on);
commit;
begin isolation level serializable;
set enable_seqscan=off; }
step "ra1" { select * from gin_tbl where p @> array[1] limit 1; }
step "rb1" { select count(*) from gin_tbl where p @> array[2]; }
step "rc1" { select count(*) from gin_tbl where p @> array[800]; }
step "rd1" { select count(*) from gin_tbl where p @> array[2000]; }
step "wo1" { insert into other_tbl values (1); }
step "rxy1" { select count(*) from gin_tbl where p @> array[4,5]; }
step "wx1" { insert into gin_tbl select g, array[5,6] from generate_series
(20001, 20050) g; }
step "rxy3" { select count(*) from gin_tbl where p @> array[1,2] or
p @> array[100,200] or p @> array[500,1000] or p @> array[1000,2000]; }
step "wx3" { insert into gin_tbl select g, array[g,g*2] from generate_series
(1, 50) g; }
step "c1" { commit; }
session "s2"
@ -51,83 +47,69 @@ setup
set enable_seqscan=off;
}
step "rxy2" { select count(*) from gin_tbl where p @> array[5,6]; }
step "rxy2fu" { select count(*) from gin_tbl where p @> array[10000,10005]; }
step "wy2" { insert into gin_tbl select g, array[4,5] from
generate_series(20051, 20100) g; }
step "wy2fu" { insert into gin_tbl select g, array[10000,10005] from
generate_series(20051, 20100) g; }
step "rxy4" { select count(*) from gin_tbl where p @> array[4000,8000] or
p @> array[5000,10000] or p @> array[6000,12000] or
p @> array[8000,16000]; }
step "wy4" { insert into gin_tbl select g, array[g,g*2] from generate_series
(10000, 10050) g; }
step "c2" { commit; }
step "ro2" { select count(*) from other_tbl; }
step "wa2" { insert into gin_tbl values (array[1]); }
step "wb2" { insert into gin_tbl values (array[2]); }
step "wc2" { insert into gin_tbl values (array[800]); }
step "wd2" { insert into gin_tbl values (array[2000]); }
# An index scan (from one transaction) and an index insert (from another transaction)
# try to access the same part of the index but one transaction commits before other
# transaction begins so no r-w conflict.
step "c2" { commit; }
permutation "rxy1" "wx1" "c1" "rxy2" "wy2" "c2"
permutation "rxy2" "wy2" "c2" "rxy1" "wx1" "c1"
session "s3"
step "fu" { alter index ginidx set (fastupdate = on); }
# An index scan (from one transaction) and an index insert (from another transaction)
# try to access different parts of the index and also one transaction commits before
# other transaction begins, so no r-w conflict.
# An index scan (from one transaction) and an index insert (from another
# transaction) try to access the same part of the index. So, there is a
# r-w conflict.
permutation "rxy3" "wx3" "c1" "rxy4" "wy4" "c2"
permutation "rxy4" "wy4" "c2" "rxy3" "wx3" "c1"
permutation "ra1" "ro2" "wo1" "c1" "wa2" "c2"
permutation "ro2" "ra1" "wo1" "c1" "wa2" "c2"
permutation "ro2" "ra1" "wo1" "wa2" "c1" "c2"
permutation "ra1" "ro2" "wa2" "wo1" "c1" "c2"
permutation "rb1" "ro2" "wo1" "c1" "wb2" "c2"
permutation "ro2" "rb1" "wo1" "c1" "wb2" "c2"
permutation "ro2" "rb1" "wo1" "wb2" "c1" "c2"
permutation "rb1" "ro2" "wb2" "wo1" "c1" "c2"
# An index scan (from one transaction) and an index insert (from another transaction)
# try to access the same part of the index and one transaction begins before other
# transaction commits so there is a r-w conflict.
permutation "rc1" "ro2" "wo1" "c1" "wc2" "c2"
permutation "ro2" "rc1" "wo1" "c1" "wc2" "c2"
permutation "ro2" "rc1" "wo1" "wc2" "c1" "c2"
permutation "rc1" "ro2" "wc2" "wo1" "c1" "c2"
permutation "rxy1" "wx1" "rxy2" "c1" "wy2" "c2"
permutation "rxy1" "wx1" "rxy2" "wy2" "c1" "c2"
permutation "rxy1" "wx1" "rxy2" "wy2" "c2" "c1"
permutation "rxy1" "rxy2" "wx1" "c1" "wy2" "c2"
permutation "rxy1" "rxy2" "wx1" "wy2" "c1" "c2"
permutation "rxy1" "rxy2" "wx1" "wy2" "c2" "c1"
permutation "rxy1" "rxy2" "wy2" "wx1" "c1" "c2"
permutation "rxy1" "rxy2" "wy2" "wx1" "c2" "c1"
permutation "rxy1" "rxy2" "wy2" "c2" "wx1" "c1"
permutation "rxy2" "rxy1" "wx1" "c1" "wy2" "c2"
permutation "rxy2" "rxy1" "wx1" "wy2" "c1" "c2"
permutation "rxy2" "rxy1" "wx1" "wy2" "c2" "c1"
permutation "rxy2" "rxy1" "wy2" "wx1" "c1" "c2"
permutation "rxy2" "rxy1" "wy2" "wx1" "c2" "c1"
permutation "rxy2" "rxy1" "wy2" "c2" "wx1" "c1"
permutation "rxy2" "wy2" "rxy1" "wx1" "c1" "c2"
permutation "rxy2" "wy2" "rxy1" "wx1" "c2" "c1"
permutation "rxy2" "wy2" "rxy1" "c2" "wx1" "c1"
# An index scan (from one transaction) and an index insert (from another
# transaction) try to access different parts of the index. So, there is no
# r-w conflict.
# An index scan (from one transaction) and an index insert (from another transaction)
# try to access different parts of the index so no r-w conflict.
permutation "ra1" "ro2" "wo1" "c1" "wb2" "c2"
permutation "ro2" "ra1" "wo1" "c1" "wc2" "c2"
permutation "ro2" "rb1" "wo1" "wa2" "c1" "c2"
permutation "rc1" "ro2" "wa2" "wo1" "c1" "c2"
permutation "rxy3" "wx3" "rxy4" "c1" "wy4" "c2"
permutation "rxy3" "wx3" "rxy4" "wy4" "c1" "c2"
permutation "rxy3" "wx3" "rxy4" "wy4" "c2" "c1"
permutation "rxy3" "rxy4" "wx3" "c1" "wy4" "c2"
permutation "rxy3" "rxy4" "wx3" "wy4" "c1" "c2"
permutation "rxy3" "rxy4" "wx3" "wy4" "c2" "c1"
permutation "rxy3" "rxy4" "wy4" "wx3" "c1" "c2"
permutation "rxy3" "rxy4" "wy4" "wx3" "c2" "c1"
permutation "rxy3" "rxy4" "wy4" "c2" "wx3" "c1"
permutation "rxy4" "rxy3" "wx3" "c1" "wy4" "c2"
permutation "rxy4" "rxy3" "wx3" "wy4" "c1" "c2"
permutation "rxy4" "rxy3" "wx3" "wy4" "c2" "c1"
permutation "rxy4" "rxy3" "wy4" "wx3" "c1" "c2"
permutation "rxy4" "rxy3" "wy4" "wx3" "c2" "c1"
permutation "rxy4" "rxy3" "wy4" "c2" "wx3" "c1"
permutation "rxy4" "wy4" "rxy3" "wx3" "c1" "c2"
permutation "rxy4" "wy4" "rxy3" "wx3" "c2" "c1"
permutation "rxy4" "wy4" "rxy3" "c2" "wx3" "c1"
permutation "rb1" "ro2" "wo1" "c1" "wa2" "c2"
permutation "ro2" "rb1" "wo1" "c1" "wc2" "c2"
permutation "ro2" "ra1" "wo1" "wb2" "c1" "c2"
permutation "rc1" "ro2" "wb2" "wo1" "c1" "c2"
# Test fastupdate = on. First test should pass because fastupdate is off and
# sessions touches different parts of index, second should fail because
# with fastupdate on, then whole index should be under predicate lock.
permutation "rc1" "ro2" "wo1" "c1" "wa2" "c2"
permutation "ro2" "rc1" "wo1" "c1" "wb2" "c2"
permutation "ro2" "ra1" "wo1" "wc2" "c1" "c2"
permutation "rb1" "ro2" "wc2" "wo1" "c1" "c2"
permutation "rxy1" "rxy2fu" "wx1" "c1" "wy2fu" "c2"
permutation "fu1" "rxy1" "rxy2fu" "wx1" "c1" "wy2fu" "c2"
# With fastupdate = on all index is under predicate lock. So we can't
# distinguish particular keys.
permutation "fu" "ra1" "ro2" "wo1" "c1" "wa2" "c2"
permutation "fu" "ra1" "ro2" "wo1" "c1" "wb2" "c2"
# Check fastupdate turned on concurrently.
permutation "ra1" "ro2" "wo1" "c1" "fu" "wa2" "c2"
# Tests for conflicts with previously non-existing key
permutation "rd1" "ro2" "wo1" "c1" "wd2" "c2"
permutation "ro2" "rd1" "wo1" "c1" "wd2" "c2"
permutation "ro2" "rd1" "wo1" "wd2" "c1" "c2"
permutation "rd1" "ro2" "wd2" "wo1" "c1" "c2"