On 04/10/2018 10:17 PM, Jan Wieck wrote:
> If your session has a transaction snapshot that protects the old toast
> slices from being vacuumed away, you are fine.
That harks back to my earlier (naïve?) thought that, as long as
my lazy datum doesn't have to outlive the transaction, lazy
detoasting might Just Work.
Tom seems to say otherwise, in
https://www.postgresql.org/message-id/23711.1522559987%40sss.pgh.pa.us
The message of the commit he mentions there includes:
I believe this code was all right when written, because our
management of a session's exposed xmin was such that the TOAST
references were safe until end of transaction. But that's
no longer true now that we can advance or clear our PGXACT.xmin
intra-transaction.
So perhaps my original thought really would have Just Worked,
in PG versions before that changed? When did that change, btw?
On 04/11/2018 09:28 AM, Amit Kapila wrote:
> Before query execution, we push the active snapshot, so any time
> during execution, if you get the active snapshot via
> GetActiveSnapshot(), you can access it. So, I think during a function
> execution, if you use GetActiveSnapshot, you should get the snapshot
> used by enclosing query.
So perhaps GetActiveSnapshot is the right choice to accompany a datum
that came as a function parameter.
For something retrieved from an SPI query within the function, it
looks like I will have a portal->holdSnapshot in certain cases
(PORTAL_ONE_RETURNING, PORTAL_ONE_MOD_WITH, PORTAL_UTIL_SELECT).
The comments added to portal.h in that commit say:
* Snapshot under which tuples in the holdStore were read. We must keep
* a reference to this snapshot if there is any possibility that the
* tuples contain TOAST references, because releasing the snapshot ...
Soo, is that telling me that the three cases named above, where
holdSnapshot gets set, are in fact the only cases where "there is any
possibility that the tuples contain TOAST references", and therefore
I could count on holdSnapshot to be nonnull whenever it matters?
-Chap