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