Commit e518fa7a authored by Alvaro Herrera's avatar Alvaro Herrera

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
parent b6ecde8e
...@@ -4824,7 +4824,16 @@ heap_lock_updated_tuple_rec(Relation rel, ItemPointer tid, TransactionId xid, ...@@ -4824,7 +4824,16 @@ heap_lock_updated_tuple_rec(Relation rel, ItemPointer tid, TransactionId xid,
ItemPointerCopy(&tupid, &(mytup.t_self)); ItemPointerCopy(&tupid, &(mytup.t_self));
if (!heap_fetch(rel, SnapshotAny, &mytup, &buf, false, NULL)) if (!heap_fetch(rel, SnapshotAny, &mytup, &buf, false, NULL))
elog(ERROR, "unable to fetch updated version of tuple"); {
/*
* if we fail to find the updated version of the tuple, it's
* because it was vacuumed/pruned away after its creator
* transaction aborted. So behave as if we got to the end of the
* chain, and there's no further tuple to lock: return success to
* caller.
*/
return HeapTupleMayBeUpdated;
}
l4: l4:
CHECK_FOR_INTERRUPTS(); CHECK_FOR_INTERRUPTS();
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment