Re: Problems with SPI memory management - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problems with SPI memory management
Date
Msg-id 4821.1095267100@sss.pgh.pa.us
Whole thread Raw
In response to Problems with SPI memory management  ("Katsaros Kwn/nos" <ntinos@aueb.gr>)
Responses Re: Problems with SPI memory management  ("Katsaros Kwn/nos" <ntinos@aueb.gr>)
Re: Problems with SPI memory management (new...)  ("Katsaros Kwn/nos" <ntinos@aueb.gr>)
List pgsql-hackers
"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.

You'd be well advised to be doing this sort of hackery in a build with
--enable-cassert.  That turns on CLOBBER_FREED_MEMORY which makes
misuse of freed memory a whole lot more obvious.
        regards, tom lane


pgsql-hackers by date:

Previous
From: James William Pye
Date:
Subject: Re: banner vs version
Next
From: Tom Lane
Date:
Subject: xact.c state machine redesign