"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