title: Why does PostgreSQL think there is a conflict between the two serializable transactions?
body: <p>I'm trying to figure out how the serializable isolation level in PostgreSQL works. In theory and according to PostgreSQL's own documentation PostgreSQL should be smart enough to somehow detect serialization conflicts and automatically roll back offending transactions. Yet when I tried to play with serializable isolation level myself I stumbled upon a lot of false positives and started to doubt my own understanding of the concept of serializability or PostgreSQL's implementation of it. Below you can find one of the simplest examples of such false positives:</p>
  
  <pre><code>create table mytab(
      class integer,
      value integer not null
  );
  
  create index mytab_class_idx on mytab (class);
  
  insert into mytab (class, value) values (1, 10);
  insert into mytab (class, value) values (1, 20);
  insert into mytab (class, value) values (2, 100);
  insert into mytab (class, value) values (2, 200);
  </code></pre>
  
  <p>The table data is the following:</p>
  
  <pre><code> class | value
  -------+-------
       1 |    10
       1 |    20
       2 |   100
       2 |   200
  </code></pre>
  
  <p>Then I run two concurrent transactions. <code>Step n</code> comments in code show an order in which I execute the statements. Following advice from <a href="https://stackoverflow.com/a/42303225/3249257">https://stackoverflow.com/a/42303225/3249257</a> I explicitly disabled sequential scan to force PostgreSQL to use an index:</p>
  
  <pre><code>SET enable_seqscan=off;
  </code></pre>
  
  <p>Transaction A:</p>
  
  <pre><code>begin; -- step 1
  select sum(value) from mytab where class = 1; -- step 2
  insert into mytab(class, value) values (3, 30); -- step 5
  commit; -- step 7
  </code></pre>
  
  <p>Transaction B:</p>
  
  <pre><code>begin; -- step 3
  select sum(value) from mytab where class = 2; -- step 4
  insert into mytab(class, value) values (4, 300); -- step 6
  commit; -- step 8
  </code></pre>
  
  <p>As I understand it, there shoudn't be any conflict between those two transactions. They don't touch the same rows. However, when I commit the second transaction it fails with this error:</p>
  
  <pre><code>[40001] ERROR: could not serialize access due to read/write dependencies among transactions
  Detail: Reason code: Canceled on identification as a pivot, during commit attempt.
  Hint: The transaction might succeed if retried.
  </code></pre>
  
  <p>What's going on here? Is my understanding of serializable isolation level flawed? Is it a failure of PostgreSQL's heuristics mentioned in this answer <a href="https://stackoverflow.com/a/50809788/3249257">https://stackoverflow.com/a/50809788/3249257</a>?</p>
  
  <p>I'm using <code>PostgreSQL 11.5 on x86_64-apple-darwin18.6.0, compiled by Apple LLVM version 10.0.1 (clang-1001.0.46.4), 64-bit</code>.</p>