Re: SPI TupTable memory context - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SPI TupTable memory context
Date
Msg-id 2588773.1638580920@sss.pgh.pa.us
Whole thread Raw
In response to SPI TupTable memory context  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: SPI TupTable memory context  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> If a person wanted to refer to those tuples after SPI_finish,
> would it be a dangerous idea to just reparent that context into one
> that will live longer, shortly before SPI_finish is called?

Seems kinda dangerous to me ...

> AtEOSubXact_SPI can free tuptables retail, but only in the rollback case.

... precisely because of that.  If you wanted to take control of
the TupTable, you'd really need to unhook it from the SPI context's
tuptables list, and that *really* seems like undue familiarity
with the implementation.

On the whole this seems like the sort of thing where if it breaks,
nobody is going to have a lot of sympathy.  What I'd suggest,
if you don't want to let the SPI mechanisms manage that memory,
is to not put the tuple set into a SPITupleTable in the first
place.  Run the query with a different DestReceiver that saves the
query result someplace you want it to be (see SPI_execute_extended
and the options->dest argument).

            regards, tom lane



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: SPI TupTable memory context
Next
From: Thomas Munro
Date:
Subject: Re: A test for replay of regression tests