Fix bugs in SSI tuple locking.

hlinnaka · hlinnaka · commit 42c63cafb2af · 2013-10-08T00:14:15.000+03:00
1. In heap_hot_search_buffer(), the PredicateLockTuple() call is passed
wrong offset number. heapTuple-&gt;t_self is set to the tid of the first
tuple in the chain that's visited, not the one actually being read.

2. CheckForSerializableConflictIn() uses the tuple's t_ctid field
instead of t_self to check for exiting predicate locks on the tuple. If
the tuple was updated, but the updater rolled back, t_ctid points to the
aborted dead tuple.

Reported by Hannu Krosing. Backpatch to 9.1.
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
@@ -1555,6 +1555,8 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
 	offnum = ItemPointerGetOffsetNumber(tid);
 	at_chain_start = true;
 
+	heapTuple->t_self = *tid;
+
 	/* Scan through possible multiple members of HOT-chain */
 	for (;;)
 	{
@@ -1586,6 +1588,7 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
 		heapTuple.t_len = ItemIdGetLength(lp);
 		heapTuple.t_tableOid = relation->rd_id;
 		heapTuple.t_self = *tid;
+		ItemPointerSetOffsetNumber(&heapTuple.t_self, offnum);
 
 		/*
 		 * Shouldn't see a HEAP_ONLY tuple at chain start.
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
@@ -4204,8 +4204,8 @@ CheckForSerializableConflictIn(Relation relation, HeapTuple tuple,
 		SET_PREDICATELOCKTARGETTAG_TUPLE(targettag,
 										 relation->rd_node.dbNode,
 										 relation->rd_id,
-						 ItemPointerGetBlockNumber(&(tuple->t_data->t_ctid)),
-						ItemPointerGetOffsetNumber(&(tuple->t_data->t_ctid)));
+								  ItemPointerGetBlockNumber(&(tuple->t_self)),
+								ItemPointerGetOffsetNumber(&(tuple->t_self)));
 		CheckTargetForConflictsIn(&targettag);
 	}
 
