GIN predicate locking slows down valgrind isolationtests tremendously

Started by Andres Freundabout 7 years ago12 messages
#1Andres Freund
andres@anarazel.de

Hi,

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-03-31%2014%3A40%3A02
isolation-check (02:19:36)

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-03-28%2010%3A40%3A02
isolation-check (00:18:44)

As far as I can tell that increase comes laregely from the new GIN
tests. Could one of you please look at keeping the test time increase
to something more reasonable?

Greetings,

Andres Freund

#2Andres Freund
andres@anarazel.de
In reply to: Andres Freund (#1)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On 2018-12-03 16:07:40 -0800, Andres Freund wrote:

Hi,

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-03-31%2014%3A40%3A02
isolation-check (02:19:36)

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-03-28%2010%3A40%3A02
isolation-check (00:18:44)

As far as I can tell that increase comes laregely from the new GIN
tests. Could one of you please look at keeping the test time increase
to something more reasonable?

Ping?

It's also one of the slowest tests outside of valgrind...

Greetings,

Andres Freund

#3Alexander Korotkov
a.korotkov@postgrespro.ru
In reply to: Andres Freund (#2)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

чт, 20 дек. 2018 г., 2:22 Andres Freund andres@anarazel.de:

On 2018-12-03 16:07:40 -0800, Andres Freund wrote:

Hi,

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-03-31%2014%3A40%3A02

isolation-check (02:19:36)

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-03-28%2010%3A40%3A02

isolation-check (00:18:44)

As far as I can tell that increase comes laregely from the new GIN
tests. Could one of you please look at keeping the test time increase
to something more reasonable?

Ping?

It's also one of the slowest tests outside of valgrind...

I'm going to take a look on that.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

#4Alexander Korotkov
a.korotkov@postgrespro.ru
In reply to: Alexander Korotkov (#3)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

чт, 20 дек. 2018 г., 2:22 Andres Freund andres@anarazel.de:

On 2018-12-03 16:07:40 -0800, Andres Freund wrote:

As far as I can tell that increase comes laregely from the new GIN
tests. Could one of you please look at keeping the test time increase
to something more reasonable?

Ping?

It's also one of the slowest tests outside of valgrind...

I'm going to take a look on that.

While trying to reduce isolation test suite for GIN, I found following
behavior surprising for me.

GinBtreeStack *
ginFindLeafPage(GinBtree btree, bool searchMode, Snapshot snapshot)
{
GinBtreeStack *stack;

stack = (GinBtreeStack *) palloc(sizeof(GinBtreeStack));
stack->blkno = btree->rootBlkno;
stack->buffer = ReadBuffer(btree->index, btree->rootBlkno);
stack->parent = NULL;
stack->predictNumber = 1;

if (!searchMode)
CheckForSerializableConflictIn(btree->index, NULL, stack->buffer);

So, we're checking for conflict on tree root for every entry insert.
That's right for posting tree, but completely unneeded for entry tree.
I'm intended to change that to lock root of only posting tree if
nobody explains me why I'm wrong...

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

#5Alexander Korotkov
a.korotkov@postgrespro.ru
In reply to: Alexander Korotkov (#3)
1 attachment(s)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

чт, 20 дек. 2018 г., 2:22 Andres Freund andres@anarazel.de:

On 2018-12-03 16:07:40 -0800, Andres Freund wrote:

As far as I can tell that increase comes laregely from the new GIN
tests. Could one of you please look at keeping the test time increase
to something more reasonable?

Ping?

It's also one of the slowest tests outside of valgrind...

I'm going to take a look on that.

BTW, patch for reducing isolation testing for gin predicate locking is
attached. Could anybody check its execution time with valgrind (and
compare with execution time of previous test suite)?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachments:

reduce-gin-predicate-locking-isolation-testing-1.patchapplication/octet-stream; name=reduce-gin-predicate-locking-isolation-testing-1.patchDownload
commit 81242568ad25d1f0255a71ce25b59c1aaee552a2
Author: Alexander Korotkov <akorotkov@postgresql.org>
Date:   Tue Dec 25 01:05:44 2018 +0300

    Reduce GIN predicate locking isolation test
    
    Isolation testing of GIN predicate locking was complaint to be too slow.  This
    commit is intended to accelerate it.  Tests were simplified in a following ways:
    
      1) Amount of data is reduced.  We now use minimal amount of data, which
         produce at least one posting tree and at least two pages of entry tree.
      2) Three isolation tests were merged into one.
      3) Query only one tuple from posting tree.  Then locking of index would be
         the same, but tuple locks wouldn't be propagated to relation lock.

diff --git a/src/test/isolation/expected/predicate-gin-fastupdate.out b/src/test/isolation/expected/predicate-gin-fastupdate.out
deleted file mode 100644
index 7d4fa8e0240..00000000000
--- a/src/test/isolation/expected/predicate-gin-fastupdate.out
+++ /dev/null
@@ -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;
diff --git a/src/test/isolation/expected/predicate-gin-nomatch.out b/src/test/isolation/expected/predicate-gin-nomatch.out
deleted file mode 100644
index 5e733262a40..00000000000
--- a/src/test/isolation/expected/predicate-gin-nomatch.out
+++ /dev/null
@@ -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;
diff --git a/src/test/isolation/expected/predicate-gin.out b/src/test/isolation/expected/predicate-gin.out
index bdf8911923b..77eb5aaff79 100644
--- a/src/test/isolation/expected/predicate-gin.out
+++ b/src/test/isolation/expected/predicate-gin.out
@@ -1,756 +1,457 @@
-Parsed test spec with 2 sessions
+Parsed test spec with 3 sessions
 
-starting permutation: rxy1 wx1 c1 rxy2 wy2 c2
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
-count          
-
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step c1: commit;
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
-count          
-
-10050          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step c2: commit;
+starting permutation: ra1 ro2 wo1 c1 wa2 c2
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-starting permutation: rxy2 wy2 c2 rxy1 wx1 c1
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+{1}            
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step c2: commit;
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
-count          
-
-10050          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step c1: commit;
-
-starting permutation: rxy3 wx3 c1 rxy4 wy4 c2
-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];
-count          
-
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-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];
-count          
-
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
-step c2: commit;
-
-starting permutation: rxy4 wy4 c2 rxy3 wx3 c1
-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];
-count          
-
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
+step wa2: insert into gin_tbl values (array[1]);
+ERROR:  could not serialize access due to read/write dependencies among transactions
 step c2: commit;
-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];
-count          
-
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step c1: commit;
 
-starting permutation: rxy1 wx1 rxy2 c1 wy2 c2
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+starting permutation: ro2 ra1 wo1 c1 wa2 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
-count          
+0              
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-10000          
+{1}            
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
+step wa2: insert into gin_tbl values (array[1]);
 ERROR:  could not serialize access due to read/write dependencies among transactions
 step c2: commit;
 
-starting permutation: rxy1 wx1 rxy2 wy2 c1 c2
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+starting permutation: ro2 ra1 wo1 wa2 c1 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
-count          
+0              
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
+{1}            
+step wo1: insert into other_tbl values (1);
+step wa2: insert into gin_tbl values (array[1]);
 step c1: commit;
 step c2: commit;
 ERROR:  could not serialize access due to read/write dependencies among transactions
 
-starting permutation: rxy1 wx1 rxy2 wy2 c2 c1
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
-count          
+starting permutation: ra1 ro2 wa2 wo1 c1 c2
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+{1}            
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step c2: commit;
+0              
+step wa2: insert into gin_tbl values (array[1]);
+step wo1: insert into other_tbl values (1);
 step c1: commit;
+step c2: commit;
 ERROR:  could not serialize access due to read/write dependencies among transactions
 
-starting permutation: rxy1 rxy2 wx1 c1 wy2 c2
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+starting permutation: rb1 ro2 wo1 c1 wb2 c2
+step rb1: select count(*) from gin_tbl where p @> array[2];
 count          
 
-10000          
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+1              
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
+step wb2: insert into gin_tbl values (array[2]);
 ERROR:  could not serialize access due to read/write dependencies among transactions
 step c2: commit;
 
-starting permutation: rxy1 rxy2 wx1 wy2 c1 c2
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+starting permutation: ro2 rb1 wo1 c1 wb2 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+0              
+step rb1: select count(*) from gin_tbl where p @> array[2];
 count          
 
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
+1              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-step c2: commit;
+step wb2: insert into gin_tbl values (array[2]);
 ERROR:  could not serialize access due to read/write dependencies among transactions
-
-starting permutation: rxy1 rxy2 wx1 wy2 c2 c1
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
-count          
-
-10000          
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
-count          
-
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
 step c2: commit;
-step c1: commit;
-ERROR:  could not serialize access due to read/write dependencies among transactions
 
-starting permutation: rxy1 rxy2 wy2 wx1 c1 c2
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+starting permutation: ro2 rb1 wo1 wb2 c1 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+0              
+step rb1: select count(*) from gin_tbl where p @> array[2];
 count          
 
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
+1              
+step wo1: insert into other_tbl values (1);
+step wb2: insert into gin_tbl values (array[2]);
 step c1: commit;
 step c2: commit;
 ERROR:  could not serialize access due to read/write dependencies among transactions
 
-starting permutation: rxy1 rxy2 wy2 wx1 c2 c1
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+starting permutation: rb1 ro2 wb2 wo1 c1 c2
+step rb1: select count(*) from gin_tbl where p @> array[2];
 count          
 
-10000          
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+1              
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step c2: commit;
+0              
+step wb2: insert into gin_tbl values (array[2]);
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-ERROR:  could not serialize access due to read/write dependencies among transactions
-
-starting permutation: rxy1 rxy2 wy2 c2 wx1 c1
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
-count          
-
-10000          
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
-count          
-
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
 step c2: commit;
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
 ERROR:  could not serialize access due to read/write dependencies among transactions
-step c1: commit;
 
-starting permutation: rxy2 rxy1 wx1 c1 wy2 c2
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+starting permutation: rc1 ro2 wo1 c1 wc2 c2
+step rc1: select count(*) from gin_tbl where p @> array[800];
 count          
 
-10000          
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+1              
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
+step wc2: insert into gin_tbl values (array[800]);
 ERROR:  could not serialize access due to read/write dependencies among transactions
 step c2: commit;
 
-starting permutation: rxy2 rxy1 wx1 wy2 c1 c2
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+starting permutation: ro2 rc1 wo1 c1 wc2 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+0              
+step rc1: select count(*) from gin_tbl where p @> array[800];
 count          
 
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
+1              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-step c2: commit;
+step wc2: insert into gin_tbl values (array[800]);
 ERROR:  could not serialize access due to read/write dependencies among transactions
-
-starting permutation: rxy2 rxy1 wx1 wy2 c2 c1
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
-count          
-
-10000          
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
-count          
-
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
 step c2: commit;
-step c1: commit;
-ERROR:  could not serialize access due to read/write dependencies among transactions
 
-starting permutation: rxy2 rxy1 wy2 wx1 c1 c2
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+starting permutation: ro2 rc1 wo1 wc2 c1 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+0              
+step rc1: select count(*) from gin_tbl where p @> array[800];
 count          
 
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
+1              
+step wo1: insert into other_tbl values (1);
+step wc2: insert into gin_tbl values (array[800]);
 step c1: commit;
 step c2: commit;
 ERROR:  could not serialize access due to read/write dependencies among transactions
 
-starting permutation: rxy2 rxy1 wy2 wx1 c2 c1
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+starting permutation: rc1 ro2 wc2 wo1 c1 c2
+step rc1: select count(*) from gin_tbl where p @> array[800];
 count          
 
-10000          
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+1              
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step c2: commit;
+0              
+step wc2: insert into gin_tbl values (array[800]);
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-ERROR:  could not serialize access due to read/write dependencies among transactions
-
-starting permutation: rxy2 rxy1 wy2 c2 wx1 c1
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
-count          
-
-10000          
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
-count          
-
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
 step c2: commit;
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
 ERROR:  could not serialize access due to read/write dependencies among transactions
-step c1: commit;
 
-starting permutation: rxy2 wy2 rxy1 wx1 c1 c2
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
-count          
+starting permutation: ra1 ro2 wo1 c1 wb2 c2
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+{1}            
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
+step wb2: insert into gin_tbl values (array[2]);
 step c2: commit;
-ERROR:  could not serialize access due to read/write dependencies among transactions
 
-starting permutation: rxy2 wy2 rxy1 wx1 c2 c1
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
+starting permutation: ro2 ra1 wo1 c1 wc2 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
-count          
+0              
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-10000          
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-step c2: commit;
+{1}            
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-ERROR:  could not serialize access due to read/write dependencies among transactions
-
-starting permutation: rxy2 wy2 rxy1 c2 wx1 c1
-step rxy2: select count(*) from gin_tbl where p @> array[5,6];
-count          
-
-10000          
-step wy2: insert into gin_tbl select g, array[4,5] from
-              generate_series(20051, 20100) g;
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
-count          
-
-10000          
+step wc2: insert into gin_tbl values (array[800]);
 step c2: commit;
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
-ERROR:  could not serialize access due to read/write dependencies among transactions
-step c1: commit;
 
-starting permutation: rxy3 wx3 rxy4 c1 wy4 c2
-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];
+starting permutation: ro2 rb1 wo1 wa2 c1 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) 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];
+0              
+step rb1: select count(*) from gin_tbl where p @> array[2];
 count          
 
-4              
+1              
+step wo1: insert into other_tbl values (1);
+step wa2: insert into gin_tbl values (array[1]);
 step c1: commit;
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
 step c2: commit;
 
-starting permutation: rxy3 wx3 rxy4 wy4 c1 c2
-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];
+starting permutation: rc1 ro2 wa2 wo1 c1 c2
+step rc1: select count(*) from gin_tbl where p @> array[800];
 count          
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) 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];
+1              
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
+0              
+step wa2: insert into gin_tbl values (array[1]);
+step wo1: insert into other_tbl values (1);
 step c1: commit;
 step c2: commit;
 
-starting permutation: rxy3 wx3 rxy4 wy4 c2 c1
-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];
+starting permutation: rb1 ro2 wo1 c1 wa2 c2
+step rb1: select count(*) from gin_tbl where p @> array[2];
 count          
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) 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];
+1              
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
-step c2: commit;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
+step wa2: insert into gin_tbl values (array[1]);
+step c2: commit;
 
-starting permutation: rxy3 rxy4 wx3 c1 wy4 c2
-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];
+starting permutation: ro2 rb1 wo1 c1 wc2 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-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];
+0              
+step rb1: select count(*) from gin_tbl where p @> array[2];
 count          
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
+1              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
+step wc2: insert into gin_tbl values (array[800]);
 step c2: commit;
 
-starting permutation: rxy3 rxy4 wx3 wy4 c1 c2
-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];
+starting permutation: ro2 ra1 wo1 wb2 c1 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-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];
-count          
+0              
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
+{1}            
+step wo1: insert into other_tbl values (1);
+step wb2: insert into gin_tbl values (array[2]);
 step c1: commit;
 step c2: commit;
 
-starting permutation: rxy3 rxy4 wx3 wy4 c2 c1
-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];
+starting permutation: rc1 ro2 wb2 wo1 c1 c2
+step rc1: select count(*) from gin_tbl where p @> array[800];
 count          
 
-4              
-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];
+1              
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
-step c2: commit;
+0              
+step wb2: insert into gin_tbl values (array[2]);
+step wo1: insert into other_tbl values (1);
 step c1: commit;
+step c2: commit;
 
-starting permutation: rxy3 rxy4 wy4 wx3 c1 c2
-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];
+starting permutation: rc1 ro2 wo1 c1 wa2 c2
+step rc1: select count(*) from gin_tbl where p @> array[800];
 count          
 
-4              
-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];
+1              
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
+step wa2: insert into gin_tbl values (array[1]);
 step c2: commit;
 
-starting permutation: rxy3 rxy4 wy4 wx3 c2 c1
-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];
+starting permutation: ro2 rc1 wo1 c1 wb2 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-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];
+0              
+step rc1: select count(*) from gin_tbl where p @> array[800];
 count          
 
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step c2: commit;
+1              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-
-starting permutation: rxy3 rxy4 wy4 c2 wx3 c1
-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];
-count          
-
-4              
-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];
-count          
-
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
+step wb2: insert into gin_tbl values (array[2]);
 step c2: commit;
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step c1: commit;
 
-starting permutation: rxy4 rxy3 wx3 c1 wy4 c2
-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];
+starting permutation: ro2 ra1 wo1 wc2 c1 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-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];
-count          
+0              
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
+{1}            
+step wo1: insert into other_tbl values (1);
+step wc2: insert into gin_tbl values (array[800]);
 step c1: commit;
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
 step c2: commit;
 
-starting permutation: rxy4 rxy3 wx3 wy4 c1 c2
-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];
+starting permutation: rb1 ro2 wc2 wo1 c1 c2
+step rb1: select count(*) from gin_tbl where p @> array[2];
 count          
 
-4              
-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];
+1              
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
+0              
+step wc2: insert into gin_tbl values (array[800]);
+step wo1: insert into other_tbl values (1);
 step c1: commit;
 step c2: commit;
 
-starting permutation: rxy4 rxy3 wx3 wy4 c2 c1
-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];
-count          
+starting permutation: fu ra1 ro2 wo1 c1 wa2 c2
+step fu: alter index ginidx set (fastupdate = on);
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-4              
-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];
+{1}            
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
-step c2: commit;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
+step wa2: insert into gin_tbl values (array[1]);
+ERROR:  could not serialize access due to read/write dependencies among transactions
+step c2: commit;
 
-starting permutation: rxy4 rxy3 wy4 wx3 c1 c2
-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];
-count          
+starting permutation: fu ra1 ro2 wo1 c1 wb2 c2
+step fu: alter index ginidx set (fastupdate = on);
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-4              
-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];
+{1}            
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
+step wb2: insert into gin_tbl values (array[2]);
+ERROR:  could not serialize access due to read/write dependencies among transactions
 step c2: commit;
 
-starting permutation: rxy4 rxy3 wy4 wx3 c2 c1
-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];
-count          
+starting permutation: ra1 ro2 wo1 c1 fu wa2 c2
+step ra1: select * from gin_tbl where p @> array[1] limit 1;
+p              
 
-4              
-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];
+{1}            
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step c2: commit;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-
-starting permutation: rxy4 rxy3 wy4 c2 wx3 c1
-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];
-count          
-
-4              
-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];
-count          
-
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) g;
+step fu: alter index ginidx set (fastupdate = on);
+step wa2: insert into gin_tbl values (array[1]);
+ERROR:  could not serialize access due to read/write dependencies among transactions
 step c2: commit;
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step c1: commit;
 
-starting permutation: rxy4 wy4 rxy3 wx3 c1 c2
-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];
+starting permutation: rd1 ro2 wo1 c1 wd2 c2
+step rd1: select count(*) from gin_tbl where p @> array[2000];
 count          
 
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) 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];
+0              
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
+step wd2: insert into gin_tbl values (array[2000]);
+ERROR:  could not serialize access due to read/write dependencies among transactions
 step c2: commit;
 
-starting permutation: rxy4 wy4 rxy3 wx3 c2 c1
-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];
+starting permutation: ro2 rd1 wo1 c1 wd2 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) 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];
+0              
+step rd1: select count(*) from gin_tbl where p @> array[2000];
 count          
 
-4              
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step c2: commit;
+0              
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-
-starting permutation: rxy4 wy4 rxy3 c2 wx3 c1
-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];
-count          
-
-4              
-step wy4: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (10000, 10050) 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];
-count          
-
-4              
+step wd2: insert into gin_tbl values (array[2000]);
+ERROR:  could not serialize access due to read/write dependencies among transactions
 step c2: commit;
-step wx3: insert into gin_tbl select g, array[g,g*2] from generate_series
-              (1, 50) g;
-step c1: commit;
 
-starting permutation: rxy1 rxy2fu wx1 c1 wy2fu c2
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+starting permutation: ro2 rd1 wo1 wd2 c1 c2
+step ro2: select count(*) from other_tbl;
 count          
 
-10000          
-step rxy2fu: select count(*) from gin_tbl where p @> array[10000,10005];
+0              
+step rd1: select count(*) from gin_tbl where p @> array[2000];
 count          
 
 0              
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
+step wo1: insert into other_tbl values (1);
+step wd2: insert into gin_tbl values (array[2000]);
 step c1: commit;
-step wy2fu: insert into gin_tbl select g, array[10000,10005] from
-              generate_series(20051, 20100) g;
 step c2: commit;
+ERROR:  could not serialize access due to read/write dependencies among transactions
 
-starting permutation: fu1 rxy1 rxy2fu wx1 c1 wy2fu c2
-step fu1: alter index ginidx set (fastupdate = on);
-			  commit;
-			  begin isolation level serializable;
-			  set enable_seqscan=off;
-step rxy1: select count(*) from gin_tbl where p @> array[4,5];
+starting permutation: rd1 ro2 wd2 wo1 c1 c2
+step rd1: select count(*) from gin_tbl where p @> array[2000];
 count          
 
-10000          
-step rxy2fu: select count(*) from gin_tbl where p @> array[10000,10005];
+0              
+step ro2: select count(*) from other_tbl;
 count          
 
 0              
-step wx1: insert into gin_tbl select g, array[5,6] from generate_series
-              (20001, 20050) g;
+step wd2: insert into gin_tbl values (array[2000]);
+step wo1: insert into other_tbl values (1);
 step c1: commit;
-step wy2fu: insert into gin_tbl select g, array[10000,10005] from
-              generate_series(20051, 20100) g;
-ERROR:  could not serialize access due to read/write dependencies among transactions
 step c2: commit;
+ERROR:  could not serialize access due to read/write dependencies among transactions
diff --git a/src/test/isolation/isolation_schedule b/src/test/isolation/isolation_schedule
index dd57a96e788..6e490d020e1 100644
--- a/src/test/isolation/isolation_schedule
+++ b/src/test/isolation/isolation_schedule
@@ -71,8 +71,6 @@ test: vacuum-skip-locked
 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
diff --git a/src/test/isolation/specs/predicate-gin-fastupdate.spec b/src/test/isolation/specs/predicate-gin-fastupdate.spec
deleted file mode 100644
index 04b8036fc56..00000000000
--- a/src/test/isolation/specs/predicate-gin-fastupdate.spec
+++ /dev/null
@@ -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"
diff --git a/src/test/isolation/specs/predicate-gin-nomatch.spec b/src/test/isolation/specs/predicate-gin-nomatch.spec
deleted file mode 100644
index 0ad456cb147..00000000000
--- a/src/test/isolation/specs/predicate-gin-nomatch.spec
+++ /dev/null
@@ -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"
diff --git a/src/test/isolation/specs/predicate-gin.spec b/src/test/isolation/specs/predicate-gin.spec
index 6a4069e995b..46fc51befd4 100644
--- a/src/test/isolation/specs/predicate-gin.spec
+++ b/src/test/isolation/specs/predicate-gin.spec
@@ -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 "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 "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 "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; }
-
-
-# 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.
-
-permutation "rxy1" "wx1" "c1" "rxy2" "wy2" "c2"
-permutation "rxy2" "wy2" "c2" "rxy1" "wx1" "c1"
-
-# 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.
-
-permutation "rxy3" "wx3" "c1" "rxy4" "wy4" "c2"
-permutation "rxy4" "wy4" "c2" "rxy3" "wx3" "c1"
-
-
-# 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 "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 no r-w conflict.
-
-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"
-
-# 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       "rxy1" "rxy2fu" "wx1" "c1" "wy2fu" "c2"
-permutation "fu1" "rxy1" "rxy2fu" "wx1" "c1" "wy2fu" "c2"
+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]); }
+
+step "c2"  { commit; }
+
+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 the same part of the index. So, there is a
+# r-w conflict.
+
+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"
+
+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"
+
+# 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.
+
+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 "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"
+
+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"
+
+# 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"
#6Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Alexander Korotkov (#5)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On 12/24/18 5:25 PM, Alexander Korotkov wrote:

On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

чт, 20 дек. 2018 г., 2:22 Andres Freund andres@anarazel.de:

On 2018-12-03 16:07:40 -0800, Andres Freund wrote:

As far as I can tell that increase comes laregely from the new GIN
tests. Could one of you please look at keeping the test time increase
to something more reasonable?

Ping?

It's also one of the slowest tests outside of valgrind...

I'm going to take a look on that.

BTW, patch for reducing isolation testing for gin predicate locking is
attached. Could anybody check its execution time with valgrind (and
compare with execution time of previous test suite)?

Will try if I get some time to spare in the next 72 hours or so

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#7Alexander Korotkov
a.korotkov@postgrespro.ru
In reply to: Andrew Dunstan (#6)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On Tue, Dec 25, 2018 at 1:48 AM Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:

On 12/24/18 5:25 PM, Alexander Korotkov wrote:

On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

чт, 20 дек. 2018 г., 2:22 Andres Freund andres@anarazel.de:

On 2018-12-03 16:07:40 -0800, Andres Freund wrote:

As far as I can tell that increase comes laregely from the new GIN
tests. Could one of you please look at keeping the test time increase
to something more reasonable?

Ping?

It's also one of the slowest tests outside of valgrind...

I'm going to take a look on that.

BTW, patch for reducing isolation testing for gin predicate locking is
attached. Could anybody check its execution time with valgrind (and
compare with execution time of previous test suite)?

Will try if I get some time to spare in the next 72 hours or so

Thank you!

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

#8Alexander Korotkov
a.korotkov@postgrespro.ru
In reply to: Alexander Korotkov (#4)
1 attachment(s)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On Tue, Dec 25, 2018 at 12:19 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

So, we're checking for conflict on tree root for every entry insert.
That's right for posting tree, but completely unneeded for entry tree.
I'm intended to change that to lock root of only posting tree if
nobody explains me why I'm wrong...

BTW, I've tried to remove conflict checking from entry tree root
(patch is attached). Neither current or my version of isolation tests
appear to be affected.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachments:

gin-remove-entry-root-conflict-check-1.patchapplication/octet-stream; name=gin-remove-entry-root-conflict-check-1.patchDownload
diff --git a/src/backend/access/gin/ginbtree.c b/src/backend/access/gin/ginbtree.c
index d5a568106c5..9a2b1287079 100644
--- a/src/backend/access/gin/ginbtree.c
+++ b/src/backend/access/gin/ginbtree.c
@@ -74,7 +74,7 @@ ginTraverseLock(Buffer buffer, bool searchMode)
  * is share-locked, and stack->parent is NULL.
  */
 GinBtreeStack *
-ginFindLeafPage(GinBtree btree, bool searchMode, Snapshot snapshot)
+ginFindLeafPage(GinBtree btree, bool searchMode, bool rootConflict, Snapshot snapshot)
 {
 	GinBtreeStack *stack;
 
@@ -84,7 +84,7 @@ ginFindLeafPage(GinBtree btree, bool searchMode, Snapshot snapshot)
 	stack->parent = NULL;
 	stack->predictNumber = 1;
 
-	if (!searchMode)
+	if (rootConflict)
 		CheckForSerializableConflictIn(btree->index, NULL, stack->buffer);
 
 	for (;;)
diff --git a/src/backend/access/gin/gindatapage.c b/src/backend/access/gin/gindatapage.c
index 9f20513811e..54d68909125 100644
--- a/src/backend/access/gin/gindatapage.c
+++ b/src/backend/access/gin/gindatapage.c
@@ -1913,7 +1913,7 @@ ginInsertItemPointers(Relation index, BlockNumber rootBlkno,
 	{
 		/* search for the leaf page where the first item should go to */
 		btree.itemptr = insertdata.items[insertdata.curitem];
-		stack = ginFindLeafPage(&btree, false, NULL);
+		stack = ginFindLeafPage(&btree, false, true, NULL);
 
 		ginInsertValue(&btree, stack, &insertdata, buildStats);
 	}
@@ -1932,7 +1932,7 @@ ginScanBeginPostingTree(GinBtree btree, Relation index, BlockNumber rootBlkno,
 
 	btree->fullScan = true;
 
-	stack = ginFindLeafPage(btree, true, snapshot);
+	stack = ginFindLeafPage(btree, true, false, snapshot);
 
 	return stack;
 }
diff --git a/src/backend/access/gin/ginget.c b/src/backend/access/gin/ginget.c
index 8466d947eab..6bfe18c359f 100644
--- a/src/backend/access/gin/ginget.c
+++ b/src/backend/access/gin/ginget.c
@@ -338,7 +338,7 @@ restartScanEntry:
 	ginPrepareEntryScan(&btreeEntry, entry->attnum,
 						entry->queryKey, entry->queryCategory,
 						ginstate);
-	stackEntry = ginFindLeafPage(&btreeEntry, true, snapshot);
+	stackEntry = ginFindLeafPage(&btreeEntry, true, false, snapshot);
 	page = BufferGetPage(stackEntry->buffer);
 
 	/* ginFindLeafPage() will have already checked snapshot age. */
@@ -679,7 +679,7 @@ entryLoadMoreItems(GinState *ginstate, GinScanEntry entry,
 						   OffsetNumberNext(GinItemPointerGetOffsetNumber(&advancePast)));
 		}
 		entry->btree.fullScan = false;
-		stack = ginFindLeafPage(&entry->btree, true, snapshot);
+		stack = ginFindLeafPage(&entry->btree, true, false, snapshot);
 
 		/* we don't need the stack, just the buffer. */
 		entry->buffer = stack->buffer;
diff --git a/src/backend/access/gin/gininsert.c b/src/backend/access/gin/gininsert.c
index 5281eb68238..2781d3fdd83 100644
--- a/src/backend/access/gin/gininsert.c
+++ b/src/backend/access/gin/gininsert.c
@@ -195,7 +195,7 @@ ginEntryInsert(GinState *ginstate,
 
 	ginPrepareEntryScan(&btree, attnum, key, category, ginstate);
 
-	stack = ginFindLeafPage(&btree, false, NULL);
+	stack = ginFindLeafPage(&btree, false, false, NULL);
 	page = BufferGetPage(stack->buffer);
 
 	if (btree.findItem(&btree, stack))
diff --git a/src/include/access/gin_private.h b/src/include/access/gin_private.h
index 81bf8734ce3..6fd91294ae9 100644
--- a/src/include/access/gin_private.h
+++ b/src/include/access/gin_private.h
@@ -195,7 +195,8 @@ typedef struct
  * PostingItem
  */
 
-extern GinBtreeStack *ginFindLeafPage(GinBtree btree, bool searchMode, Snapshot snapshot);
+extern GinBtreeStack *ginFindLeafPage(GinBtree btree, bool searchMode,
+				bool rootConflict, Snapshot snapshot);
 extern Buffer ginStepRight(Buffer buffer, Relation index, int lockmode);
 extern void freeGinBtreeStack(GinBtreeStack *stack);
 extern void ginInsertValue(GinBtree btree, GinBtreeStack *stack,
#9Alexander Korotkov
a.korotkov@postgrespro.ru
In reply to: Alexander Korotkov (#8)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On Tue, Dec 25, 2018 at 4:32 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

On Tue, Dec 25, 2018 at 12:19 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

So, we're checking for conflict on tree root for every entry insert.
That's right for posting tree, but completely unneeded for entry tree.
I'm intended to change that to lock root of only posting tree if
nobody explains me why I'm wrong...

BTW, I've tried to remove conflict checking from entry tree root
(patch is attached). Neither current or my version of isolation tests
appear to be affected.

Given no comments yet, I'll commit this on no objection.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

#10Alexander Korotkov
a.korotkov@postgrespro.ru
In reply to: Alexander Korotkov (#5)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On Tue, Dec 25, 2018 at 1:25 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

чт, 20 дек. 2018 г., 2:22 Andres Freund andres@anarazel.de:

On 2018-12-03 16:07:40 -0800, Andres Freund wrote:

As far as I can tell that increase comes laregely from the new GIN
tests. Could one of you please look at keeping the test time increase
to something more reasonable?

Ping?

It's also one of the slowest tests outside of valgrind...

I'm going to take a look on that.

BTW, patch for reducing isolation testing for gin predicate locking is
attached. Could anybody check its execution time with valgrind (and
compare with execution time of previous test suite)?

I've managed to run it myself. I've added following lines to
src/test/isolation/Makefile to make it handy running these tests under
valgrind.

ifdef VALGRIND
override with_temp_install += PGCTLTIMEOUT=600 \
valgrind --leak-check=no --gen-suppressions=all \
--suppressions=../../tools/valgrind.supp --time-stamp=yes \
--log-file=pid-%p.log --trace-children=yes \
--trace-children-skip=*/initdb
endif

With only predicate-gin in isolation_schedule patched version takes
less than minute.

real 0m53.866s
user 0m9.472s
sys 0m1.706s

I also run unpatched version of predicate-gin test, but cancel that
after 30 minutes of waiting. So, it appears that patch solves the
problem. I'm going to commit it if no objections.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

#11Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Andrew Dunstan (#6)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On 12/24/18 5:47 PM, Andrew Dunstan wrote:

On 12/24/18 5:25 PM, Alexander Korotkov wrote:

On Fri, Dec 21, 2018 at 1:50 AM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:

чт, 20 дек. 2018 г., 2:22 Andres Freund andres@anarazel.de:

On 2018-12-03 16:07:40 -0800, Andres Freund wrote:

As far as I can tell that increase comes laregely from the new GIN
tests. Could one of you please look at keeping the test time increase
to something more reasonable?

Ping?

It's also one of the slowest tests outside of valgrind...

I'm going to take a look on that.

BTW, patch for reducing isolation testing for gin predicate locking is
attached. Could anybody check its execution time with valgrind (and
compare with execution time of previous test suite)?

Will try if I get some time to spare in the next 72 hours or so

The latest test on lousyjack ran with this applied. The isolation tests
went from 285 minutes to 65 minutes.

So +1 for applying this.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#12Alexander Korotkov
a.korotkov@postgrespro.ru
In reply to: Andrew Dunstan (#11)
Re: GIN predicate locking slows down valgrind isolationtests tremendously

On Thu, Dec 27, 2018 at 7:58 PM Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:

On 12/24/18 5:47 PM, Andrew Dunstan wrote:

On 12/24/18 5:25 PM, Alexander Korotkov wrote:

BTW, patch for reducing isolation testing for gin predicate locking is
attached. Could anybody check its execution time with valgrind (and
compare with execution time of previous test suite)?

Will try if I get some time to spare in the next 72 hours or so

The latest test on lousyjack ran with this applied. The isolation tests
went from 285 minutes to 65 minutes.

So +1 for applying this.

Thank you very much!
So, pushed.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company