Re: Problems with SPI memory management (new...) - Mailing list pgsql-hackers

From Katsaros Kwn/nos
Subject Re: Problems with SPI memory management (new...)
Date
Msg-id 1095411017.6695.16.camel@localhost.localdomain
Whole thread Raw
In response to Re: Problems with SPI memory management  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2004-09-15 at 19:51, Tom Lane wrote:
> "Katsaros Kwn/nos" <ntinos@aueb.gr> writes:
> > What I'm trying to do is to get the Query related to a select statement,
> > alter it and produce a new SPI_plan that will execute. To do so, I
> > retrieve the query from the _SPI_plan->qtlist, alter it (seems OK in
> > nodeToString) and then use some SPI functions copied in my code to
> > produce the new _SPI_plan. In more details, I begin a new my_SPI
> > session, call my_SPI_prepare and pass the query. The code is almost the
> > same with that in spi.c apart from that I do not call pg_parse and
> > pg_analyze_and_rewrite.Then I begin a new SPI session and pass the new
> > plan.
> 
> What do you mean by "begin a new SPI session" --- do you SPI_finish()
> and SPI_connect()?  (If so, why bother?)  I think that SPI_finish()
> would release the memory in which the previous plan existed.  If you're
> not copying the entire parse tree this would lead to trouble.

After all these, I managed to transform a query like 
"select * from t1 where age>8 and age<50" into an even simpler:
"select * from t1 where age>8". This works fine (big deal....:-) ).

The new problem is when I try to alter a select statement like this:
"select t1.name,t2.age from t1,t2 where t1.name=t2.name and t2.age>2".
Even if I don't try to alter the query structure ,by just giving the old
Query to the planner, the system crashes (signal 11, something goes
wrong with memory references) instead of returning the same plan back.
The strange thing is that with "debug_print_plan = true" the planner
returns a plan completly different than expected (i.e. returned by
explain verbose) and then crashes.

Any ideas...?

Regards,
Ntinos Katsaros





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PL/PgSQL "bare" function calls
Next
From: Andreas Pflug
Date:
Subject: Re: problem permission on view