Re: lazy detoasting

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема Re: lazy detoasting
Дата
Msg-id 5ACC5D87.9050708@anastigmatix.net
обсуждение исходный текст
Ответ на Re: lazy detoasting  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: lazy detoasting  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 04/10/18 00:30, Andrew Gierth wrote:

> That's not precisely true - ultimately, the routines that do actual
> scans take the snapshot to use as a parameter, and the executor mostly
> references the snapshot from the EState; but a bunch of places do
> require that ActiveSnapshot be set to the currently applicable snapshot
> (e.g. for queries inside stable functions nested inside the main query).

I'm becoming increasingly glad I asked (or less embarrassed that I hadn't
figured it all out yet).  :)

Am I right in thinking that, for my original purpose of detoasting something
later in a transaction, all that matters is that I registered a snapshot
from the time at which I copied the toasted datum, and the resource owner
I registered it to has not been released yet, so rows referred to in the
snapshot haven't been vacuumed away? Is that a sufficient condition for
detoast to work?

Or would I need to do something more, like push and pop that snapshot
around the detoast call?

This would be in a PL function (or the handler for the PL function),
if the context matters.

-Chap


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [sqlsmith] Failed assertion on pfree() viaperform_pruning_combine_step
Следующее
От: Jeevan Chalke
Дата:
Сообщение: Re: [sqlsmith] Failed assertion in create_gather_path