title: Postgres: SELECT FOR UPDATE does not see new rows after lock release
body: <p>Trying to support PostgreSQL DB in my application, found this strange behaviour.</p>
  
  <p><strong>Preparation:</strong></p>
  
  <pre><code>CREATE TABLE test(id INTEGER, flag BOOLEAN);
  INSERT INTO test(id, flag) VALUES (1, true);
  </code></pre>
  
  <p>Assume two concurrent transactions (<em>Autocommit=false, READ_COMMITTED</em>) <strong>TX1</strong> and <strong>TX2</strong>:</p>
  
  <p><strong>TX1:</strong></p>
  
  <pre><code>UPDATE test SET flag = FALSE WHERE id = 1;
  INSERT INTO test(id, flag) VALUES (2, TRUE);
  -- (wait, no COMMIT yet)
  </code></pre>
  
  <p><strong>TX2:</strong></p>
  
  <pre><code>SELECT id FROM test WHERE flag=true FOR UPDATE;
  -- waits for TX1 to release lock
  </code></pre>
  
  <p>Now, if I <strong>COMMIT</strong> in <strong>TX1</strong>, the SELECT in TX2 returns empty cursor.</p>
  
  <p>It is strange to me, because same experiment in Oracle and MariaDB results in selecting newly created row (id=2).</p>
  
  <p>I could not find anything about this behaviour in PG documentation.
  Am I missing something?
  Is there any way to force PG server to "refresh" statement visibility after acquiring lock?</p>
  
  <p>PS: PostgreSQL version 11.1</p>