On 04/10/2018 10:06 AM, Tom Lane wrote: > Chapman Flack <c...@anastigmatix.net> writes:
>> 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, ... > > I believe so. Ok. I see I have about half a dozen choices for the snapshot that I choose to squirrel away at the same time as the copied datum. (That's not counting SnapshotToast, which I didn't know was a thing until Pavan's thread this morning, but it's not a thing I can get, just something constructed on the fly in the tuptoaster.) Out of the six GetFooSnapshot()s, would I want to squirrel away Active? Oldest? Transaction? This should be happening in a PL function not doing anything arcane; the datum in question might be passed to it as a parameter or retrieved from a query done within the function. GetOldestTransaction() is what the tuptoaster will eventually use to construct SnapshotToast when looking for the data, but it's probably overkill for me to save the oldest one in sight at the time I save the datum. Or is it? Should I be confident that, at the time I'm handed this datum, its toasted content must be retrievable through the (Active? Transaction?) snapshot at that moment, and it's enough to register that, while to register the Oldest would be to pin something unnecessarily far back? > Wouldn't be a bad idea to test this, of course ;-) Mm-hmm. (Thunderbird has just corrected my spelling of mm-hmm.) I'm still not sure I know enough to construct a meaningful test... I assume that, while I'm doing this for a backend PL at the moment, some of the same considerations will apply if a future wire protocol is to support Craig's "v4 protocol TODO item - Lazy fetch/stream of TOASTed valued" suggestion in https://www.postgresql.org/message-id/53ff0ef8....@2ndquadrant.com -Chap
