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

Commit e518fa7

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 b6ecde8 commit e518fa7

File tree

1 file changed

+10
-1
lines changed

1 file changed

+10
-1
lines changed

src/backend/access/heap/heapam.c

+10-1
Original file line numberDiff line numberDiff line change
@@ -4824,7 +4824,16 @@ heap_lock_updated_tuple_rec(Relation rel, ItemPointer tid, TransactionId xid,
48244824
ItemPointerCopy(&tupid, &(mytup.t_self));
48254825

48264826
if (!heap_fetch(rel, SnapshotAny, &mytup, &buf, false, NULL))
4827-
elog(ERROR, "unable to fetch updated version of tuple");
4827+
{
4828+
/*
4829+
* if we fail to find the updated version of the tuple, it's
4830+
* because it was vacuumed/pruned away after its creator
4831+
* transaction aborted. So behave as if we got to the end of the
4832+
* chain, and there's no further tuple to lock: return success to
4833+
* caller.
4834+
*/
4835+
return HeapTupleMayBeUpdated;
4836+
}
48284837

48294838
l4:
48304839
CHECK_FOR_INTERRUPTS();

0 commit comments

Comments
 (0)