On Thu, 2008-09-25 at 11:14 +0200, Zeugswetter Andreas OSB sIT wrote:
> > Simon Riggs wrote:
> > > 2. Master ignores Standby's OldestXmin
> > > Effects:
> > > * Long running queries on standby...
> > > Have no effect on primary
> > > Can delay apply of WAL records on standby
> > > * Queries on standby give consistent answers in all cases.
> >
> > Just for clarification, if you set a max_slave_delay it means it is the
> > maximum amount of time WAL replay can be delayed on the slave, _and_ it
> > is the maximum amount of time a query/snapshot can be guaranteed to run
> > without the possibility of being canceled. My point is that these two
> > concepts are linked to the same setting.
>
> 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.
We might also make HOT and VACUUM slightly less aggressive at removing
rows on the master. We can't use later than OldestXmin for row removal,
but we might choose to use something earlier. That would be an
alternative to using the standby's OldestXmin.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
