Re: Crash on UPDATE in 7.0beta3

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

In response to

Browse pgsql-hackers by date

  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