> > I wonder whether the cancel can be delayed until a tuple/page is actually accessed
> > that shows a too new xid.
>
> Yes, its feasible and is now part of the design.
>
> This is all about what happens *if* we need to remove rows that a query
> can still see.
I was describing a procedure for exactly that case.
If a slave backend has a snapshot that we cannot guarantee any more
(because max_slave_delay has been exceeded):
> > Instead of cancel, the backend gets a message with a lsn_horizon.
> > From there on, whenever the backend reads a page/tuple with a LSN > lsn_horizon it cancels.
but not before (at the time max_slave_delay has been reached), as described earlier.
Andreas
