Re: Core dump on PG 7.1.3

The upgrade went smoothly and I am unable to replicate the core dump on the
new version of Postgres ...

Thanks for all of your help ... Postgres is a really dynamite db ..

-dave

> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org
> [mailto:pgsql-general-owner(at)postgresql(dot)org]On Behalf Of David Esposito
> Sent: Tuesday, April 02, 2002 1:03 PM
> To: Tom Lane
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] 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(at)postgresql(dot)org
> > [mailto:pgsql-general-owner(at)postgresql(dot)org]On Behalf Of Tom Lane
> > Sent: Tuesday, April 02, 2002 12:05 PM
> > To: David Esposito
> > Cc: pgsql-general(at)postgresql(dot)org
> > Subject: Re: [GENERAL] Core dump on PG 7.1.3
> >
> >
> > "David Esposito" <dvesposito(at)newnetco(dot)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(at)postgresql(dot)org so that your
> > message can get through to the mailing list cleanly
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)