Re: Core dump on PG 7.1.3

Thanks ... I'll do that in the wee hours of tomorrow morning and let you
know how it turns out ...

Thanks for the quick responses ...

-Dave

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Tom Lane
> Sent: Tuesday, April 02, 2002 12:05 PM
> To: David Esposito
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Core dump on PG 7.1.3
>
>
> "David Esposito" <dvesposito@newnetco.com> writes:
> > (gdb) p *variable
> > $2 = {type = T_Var, varno = 65001, varattno = 3, vartype = 23, vartypmod
> > = -1, varlevelsup = 0, varnoold = 2, varoattno = 11}
> > (gdb) p *econtext
> > $3 = {type = T_ExprContext, ecxt_scantuple = 0x82374c0,
> ecxt_innertuple =
> > 0x0, ecxt_outertuple = 0x0,
> >   ecxt_per_query_memory = 0x81dc7f8, ecxt_per_tuple_memory = 0x822f030,
> > ecxt_param_exec_vals = 0x0, ecxt_param_list_info = 0x0,
> >   ecxt_aggvalues = 0x0, ecxt_aggnulls = 0x0}
>
> Hmm ... trying to access an "OUTER" variable in a context that has no
> outer tuple ... and it's called from EvalPlanQual ... yes, this is a
> known bug.  I believe it's the same case addressed by this recent fix:
>
> 2002-02-11 15:10  tgl
>
>     * src/backend/executor/: nodeIndexscan.c, nodeTidscan.c: Repair
>     problems with EvalPlanQual where target table is scanned as inner
>     indexscan (ie, one with runtime keys).    ExecIndexReScan must
>     compute or recompute runtime keys even if we are rescanning in the
>     EPQ case.  TidScan seems to have comparable problems.  Per bug
>     noted by Barry Lind 11-Feb-02.
>
> The EvalPlanQual path is only taken in concurrent-update scenarios;
> probably the reason you could not reproduce the problem on your devel
> box is that you executed the query in isolation, not in competition
> with other updates on the same rows.
>
> This fix is in 7.2.1 --- it is *not* in 7.2.  If you can afford to
> update your production box to 7.2.1 now, that's the approach I'd
> recommend.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly