Re: Core dump on PG 7.1.3
От | David Esposito |
---|---|
Тема | Re: Core dump on PG 7.1.3 |
Дата | |
Msg-id | PEEDKNLDICKECFBNGNLLMECCEPAA.dvesposito@newnetco.com обсуждение исходный текст |
Ответ на | Re: Core dump on PG 7.1.3 ("David Esposito" <dvesposito@newnetco.com>) |
Список | pgsql-general |
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@postgresql.org > [mailto:pgsql-general-owner@postgresql.org]On Behalf Of David Esposito > Sent: Tuesday, April 02, 2002 1:03 PM > To: Tom Lane > Cc: pgsql-general@postgresql.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@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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
В списке pgsql-general по дате отправления: