SPI TupTable memory context - Mailing list pgsql-hackers

From Chapman Flack
Subject SPI TupTable memory context
Date
Msg-id 61AAB9A8.6030501@anastigmatix.net
Whole thread Raw
Responses Re: SPI TupTable memory context
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: "Euler Taveira"
Date:
Subject: Re: row filtering for logical replication
Next
From: Tom Lane
Date:
Subject: Re: SPI TupTable memory context