> > Well this is certainly interesting. What do we think it
> would take to
> > enable the functionality?
>
> First we must run the query in serializable mode and replace
> the snapshot with a synthetic one, which defines visibility
> at the start of the desired transaction
We could use something that controls "global xmin".
It would ensure, that global xmin does not advance bejond
what still needs to be visible. This would probably be a
sliding time window, or a fixed point in time that is
released by the dba/user.
Then all below is not really different from a situation where
you had a long running tx.
> probably it is a good idea to take a lock on all tables
> involved to avoid a vacuum to be started on them when the
> query is running.
>
> also, we can't trust the DELETED flags in index pages, so we
> should forbid index scans, or just always re-check the
> visibility in heap.
>
> Otherways it would probably be enough to just scan tuples as
> usual, and check if they were visible to desired transaction,
> that is they were inserted before that transaction and they
> are not deleted before that trx.
>
> Of course this will not be true, once we have HOT/WIP with
> in-page vacuuming.
Currently I think HOT does honor "global xmin". There is no
lookup for relevant xids, so parts of an update chain where
only a previous tuple or a later tuple can be visible are reused.
Else Hot would need to be told not to, in a scenario where
a backend can choose a snapshot at will.
Andreas
