> > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
