I said:
> ... But I don't
> understand why having other backends running concurrently would affect
> this.
Yes I do: this entire path of control is only invoked if ExecReplace
discovers that the tuple it's trying to update is already updated by
a concurrent transaction. Evidently no one's tried running concurrent
UPDATEs where the updates use a nestloop+inner indexscan join plan,
because this path is certain to fail in that case.
Magnus, try swapping the code segments in ExecIndexReScan()
(executor/nodeIndexscan.c:341 ff) to become
/* it's possible in subselects */ if (exprCtxt == NULL) exprCtxt =
node->scan.scanstate->cstate.cs_ExprContext;
node->scan.scanstate->cstate.cs_ExprContext->ecxt_outertuple = exprCtxt->ecxt_outertuple;
/* If this is re-scanning of PlanQual ... */ if (estate->es_evTuple != NULL &&
estate->es_evTuple[node->scan.scanrelid- 1] != NULL) { estate->es_evTupleNull[node->scan.scanrelid - 1] =
false; return; }
and see if that makes things more reliable.
It looks like nodeTidscan has the same bug...
regards, tom lane
