From 2d227750252da8e66849525f7ca5879cd2e0cb7d Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Wed, 27 Nov 2013 17:45:25 -0300 Subject: [PATCH 2/5] 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 --- src/backend/access/heap/heapam.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index 32ef453..6d7cd0c 100644 --- a/src/backend/access/heap/heapam.c +++ b/src/backend/access/heap/heapam.c @@ -4829,7 +4829,16 @@ heap_lock_updated_tuple_rec(Relation rel, ItemPointer tid, TransactionId xid, ItemPointerCopy(&tupid, &(mytup.t_self)); 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: CHECK_FOR_INTERRUPTS(); -- 1.7.10.4