Thread: SPI TupTable memory context

Hi,

When SPI produces a tuple table result, its DestReceiver makes a new
"SPI TupTable" memory context, as a child of the SPI Proc context,
and the received tuples get copied into it. It goes away at SPI_finish,
as a consequence of its parent SPI Proc context going away.

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?

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

The idea makes sense to me, only I notice that SPITupleTable.tuptabcxt
is under /* Private members, not intended for external callers */.

There's no such warning painted on GetMemoryChunkContext, but it would be
hard to get the Woody Guthrie song out of my head after doing it that way.

Am I overlooking a reason that reparenting an SPI TupTable context
would be a bad idea?

Regards,
-Chap

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

On 12/03/21 20:22, Tom Lane wrote:
> 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.

Fair enough. I didn't have an immediate use in mind, but had been reading
through DestReceiver code and noticed it worked that way, and that it
looked as if an SPI_keeptuptable could have been implemented in probably
no more than the 25 lines of SPI_keepplan, and I wasn't sure if that was
because it had been considered and deemed a Bad Thing, or because the idea
hadn't come up.

The equivalent with a custom DestReceiver would certainly work, but with
a lot more ceremony.

So that was why I asked. If the response had been more like "hmm, no clear
reason a patch to do that would be bad", and if such a patch got accepted
for PG release n, that could also implicitly assuage worries about undue
familiarity for implementing the compatible behavior when building on < n.

Regards,
-Chap