Re: lazy detoasting
| От | Tom Lane |
|---|---|
| Тема | Re: lazy detoasting |
| Дата | |
| Msg-id | 18065.1523369184@sss.pgh.pa.us обсуждение |
| Ответ на | Re: lazy detoasting (Chapman Flack <chap@anastigmatix.net>) |
| Ответы |
Re: lazy detoasting
|
| Список | pgsql-hackers |
Chapman Flack <chap@anastigmatix.net> writes:
> 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?
I believe so.
> Or would I need to do something more, like push and pop that snapshot
> around the detoast call?
You shouldn't need that; toast reads intentionally use a non-MVCC-aware
"snapshot" to handle exactly this type of situation, where somebody is
trying to pull data out of a tuple that would no longer be visible to
the transaction's current snapshot.
Wouldn't be a bad idea to test this, of course ;-)
regards, tom lane
В списке pgsql-hackers по дате отправления: