From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Crash on UPDATE in 7.0beta3 |
Date: | 2000-04-02 17:30:05 |
Message-ID: | 3544.954696605@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff MacDonald | 2000-04-02 17:53:58 | Re: Call for porting reports |
Previous Message | Tom Lane | 2000-04-02 17:06:05 | Re: Crash on UPDATE in 7.0beta3 |