Re: SPI TupTable memory context

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SPI TupTable memory context
Дата
Msg-id 2588773.1638580920@sss.pgh.pa.us
обсуждение исходный текст
Ответ на SPI TupTable memory context  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: SPI TupTable memory context  (Chapman Flack <chap@anastigmatix.net>)
Список 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 по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: SPI TupTable memory context
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: A test for replay of regression tests