Core dump on PG 7.1.3 
Author Message
 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

Quote:
> -----Original Message-----


> Sent: Tuesday, April 02, 2002 12:05 PM
> To: David Esposito

> Subject: Re: [GENERAL] Core dump on PG 7.1.3


> > (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

> 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



Sun, 19 Sep 2004 02:58:20 GMT
 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

Quote:
> -----Original Message-----


> Sent: Tuesday, April 02, 2002 1:03 PM
> To: Tom Lane

> 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-----


> > Sent: Tuesday, April 02, 2002 12:05 PM
> > To: David Esposito

> > Subject: Re: [GENERAL] Core dump on PG 7.1.3


> > > (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

> > 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


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster


Mon, 20 Sep 2004 03:08:38 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. PG 7.2.1 core dump

2. Building perl mods pg:PG or DBD:PG on non-PostgreSQLable machines

3. Building perl mods pg:PG or DBD:PG on non

4. postgres 7.0.3 core dumps

5. Java Web Server Core Dump

6. Oracle oci driver: Core dump-oci parameter passed

7. postmaster core dumps with SPI_repalloc

8. Fix for possible pg_dump core dump

9. Core Dump

10. postgres core dump PS

11. Core dump on 7.1.3 on Linux 2.2.19

12. Core dump on HP


 
Powered by phpBB® Forum Software