Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit fbface6

Browse files
committed
Cope with heap_fetch failure while locking an update chain
The reason for the fetch failure is that the tuple was removed because it was dead; so the failure is innocuous and can be ignored. Moreover, there's no need for further work and we can return success to the caller immediately. EvalPlanQualFetch is doing something very similar to this already. Report and test case from Andres Freund in 20131124000203.GA4403@alap2.anarazel.de
1 parent 19ffa95 commit fbface6

File tree

1 file changed

+10
-1
lines changed

1 file changed

+10
-1
lines changed

src/backend/access/heap/heapam.c

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4807,7 +4807,16 @@ heap_lock_updated_tuple_rec(Relation rel, ItemPointer tid, TransactionId xid,
48074807
ItemPointerCopy(&tupid, &(mytup.t_self));
48084808

48094809
if (!heap_fetch(rel, SnapshotAny, &mytup, &buf, false, NULL))
4810-
elog(ERROR, "unable to fetch updated version of tuple");
4810+
{
4811+
/*
4812+
* if we fail to find the updated version of the tuple, it's
4813+
* because it was vacuumed/pruned away after its creator
4814+
* transaction aborted. So behave as if we got to the end of the
4815+
* chain, and there's no further tuple to lock: return success to
4816+
* caller.
4817+
*/
4818+
return HeapTupleMayBeUpdated;
4819+
}
48114820

48124821
l4:
48134822
CHECK_FOR_INTERRUPTS();

0 commit comments

Comments
 (0)