On Wed, 2008-09-24 at 21:22 -0400, Bruce Momjian wrote:
> Bruce Momjian 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.
>
> FYI, max_slave_delay does not relate to the amount of time of data loss
> in the case of master failure, assuming the WAL files are stored on the
> slave in some way during the delay.
Another way to handle row removal would be to check whether any users
have access to particular tables or not. If we could issue a permission
to prevent access to security definer functions, then we'd be able to
work out with certainty whether a row removal would ever be visible to
certain users. That would allow us to isolate fast changing tables from
slow changing ones.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
