Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Jeff MacDonaldDate: 2000-04-02 17:53:58
Subject: Re: Call for porting reports
Previous:From: Tom LaneDate: 2000-04-02 17:06:05
Subject: Re: Crash on UPDATE in 7.0beta3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group