Add isolation tests for UPDATE/DELETE FOR PORTION OF

Concurrent updates/deletes in READ COMMITTED mode don't give you what you want:
the second update/delete fails to leftovers from the first, so you essentially
have lost updates/deletes. But we are following the rules, and other RDBMSes
give you screwy results in READ COMMITTED too (albeit different).

One approach is to lock the history you want with SELECT FOR UPDATE before
issuing the actual UPDATE/DELETE. That way you see the leftovers of anyone else
who also touched that history. The isolation tests here use that approach and
show that it's viable.

Author: pjungwir

doc/src/sgml/dml.sgml

@@ -394,6 +394,22 @@ WHERE id = 5;
    column references are not.
   </para>
 
+  <para>
+   In <literal>READ COMMITTED</literal> mode, temporal updates and deletes can
+   cause unexpected results when they concurrently touch the same row. It is
+   possible to lose all or part of the second update or delete. That's because
+   after the first update changes the start/end times of the original
+   record, it may no longer fit within the second query's <literal>FOR PORTION
+   OF</literal> bounds, so it becomes disqualified from the query. On the other
+   hand the just-inserted temporal leftovers may be overlooked by the second query,
+   which has already scanned the table to find rows to modify. To solve these
+   problems, precede every temporal update/delete with a <literal>SELECT FOR
+   UPDATE</literal> matching the same criteria (including the targeted portion of
+   application time). That way the actual update/delete doesn't begin until the
+   lock is held, and all concurrent leftovers will be visible. In other
+   transaction isolation levels, this lock is not required.
+  </para>
+
   <para>
    When temporal leftovers are inserted, all <literal>INSERT</literal>
    triggers are fired, but permission checks for inserting rows are

src/backend/executor/nodeModifyTable.c

@@ -1403,6 +1403,10 @@ ExecForPortionOfLeftovers(ModifyTableContext *context,
 	 * We have already locked the tuple in ExecUpdate/ExecDelete, and it has
 	 * passed EvalPlanQual. This ensures that concurrent updates in READ
 	 * COMMITTED can't insert conflicting temporal leftovers.
+	 *
+	 * It does *not* protect against concurrent update/deletes overlooking each
+	 * others' leftovers though. See our isolation tests for details about that
+	 * and a viable workaround.
 	 */
 	if (!table_tuple_fetch_row_version(resultRelInfo->ri_RelationDesc, tupleid, SnapshotAny, oldtupleSlot))
 		elog(ERROR, "failed to fetch tuple for FOR PORTION OF");