title: apparent transaction isolation violation in postgresql
body: <p>I am using PostgreSQL 9.3.12 on CentOS Linux.</p>
  
  <p>I have two processes connecting to the same database, using a default transaction isolation level of "read committed". According to the postgres docs, one process in a transaction should not "see" changes made by another process in a transaction until they are committed.</p>
  
  <p>A sequence I am seeing is:</p>
  
  <ul>
  <li>process A starts its transaction</li>
  <li>process A deletes everything from table T</li>
  <li>process B starts its transaction</li>
  <li>process B attempts a select for update on one row in table T</li>
  <li>process B comes up empty (0 rows) and calls rollback</li>
  <li>process A repopulates table T from incoming data</li>
  <li>process A commits its transaction</li>
  </ul>
  
  <p>Now, table T should have been populated before both transactions began, and process B's query should have turned up one row. And it does if these processes do not run concurrently.</p>
  
  <p>My understanding is that process B should see the old copy of the desired row in table T, makes its changes, and those changes should be clobbered by process A's deletion and repopulation of table T. I can't figure out why process B is coming up empty.</p>
  
  <p>Beyond a complete misunderstanding by myself of these preconditions, can anyone think of another reason why I would see this behaviour?</p>
  
  <p>Worry not about the lousy architecture, it is going away. I'm just trying to understand why this situation seems to violate the "read committed" transaction isolation as I understand it.</p>
  
  <p>Thanks. </p>