1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix bugs in SSI tuple locking.

Browse Source 
1. In heap_hot_search_buffer(), the PredicateLockTuple() call is passed
wrong offset number. heapTuple->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.
This commit is contained in:
Heikki Linnakangas 2013-10-07 23:57:40 +03:00
parent 1c4dfd19a6
commit 42c63cafb2
2 changed files with 5 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
src/backend/access/heap/heapam.c
View File

@ -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.

4
src/backend/storage/lmgr/predicate.c
View File

@ -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);
}