Simon Riggs <simon@2ndquadrant.com> writes:
> If we had a function
> replace_serializable_snapshot(master_xid, txid_snapshot)
> this would allow us to use the txid_snapshot values to replace our
> transaction's serializable snapshot.
... whereupon we'd get wrong answers. Certainly you could not allow
transaction xmin to go backwards, and I'm not sure what other
restrictions there would be, but the whole thing gives me the willies.
> What I'm thinking about is how we might use this to have multiple
> sessions working simultaneously on tasks like unloading data,
Then what you want is a function that says "clone the snapshot of that
specified other transaction". Not a function that lets the user
substitute random snapshot data and tell you he thinks it's valid.
The user isn't going to have any legal way to transfer the data between
backends anyway, since no transaction can see results of an uncommitted
other transaction. There *has* to be some backdoor channel involved
there, and you might as well make it carry the data without the user
touching it.
The whole thing seems a bit backwards anyway. What you'd really want
for ease of use is some kind of "fork this session" operation, that
is push the info to a new process not pull it.
regards, tom lane