Andres Freund <andres@anarazel.de> writes:
> On 2021-05-12 11:37:46 -0400, Tom Lane wrote:
>> ISTM there are two ways we could look at this:
>>
>> 1. COMMIT is dropping the ball by not forcing there to be any
>> registered transaction-level snapshot afterward. (Maybe it's
>> not exactly COMMIT that must do this, but in any case the
>> snapshot situation after COMMIT is clearly different from
>> normal running, and that seems highly bug-prone.)
>>
>> 2. GetOldestSnapshot ought to be willing to fall back to
>> CurrentSnapshot if FirstSnapshotSet is true but there are
>> no active or registered snapshots. But it's not clear how
>> its promises about returning the "oldest" snapshot would apply.
> FirstSnapshotSet doesn't indicate the snapshot is usable, unless
> IsolationUsesXactSnapshot() - in which case it also registers the
> snapshot. We don't maintain MyProc->xmin outside of that, which I think
> means we can't rely on the snapshot at all? Or am I missing something?
Yeah, on further thought, the real question to be asking here is
"what's protecting that in-flight datum from becoming a dangling
pointer?". AFAICT, the answer right now is "nothing". Therefore,
it is *never* okay for plpgsql to be executing without a registered
transaction snapshot; and it seems quite unlikely that it'd be any
safer for any other PL.
I'm batting the ball back into Peter's court.
regards, tom lane