Re: Crash on UPDATE in 7.0beta3

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