On Wed, 2009-09-30 at 18:45 +0300, Heikki Linnakangas wrote: > Regarding this in InitStandbyDelayTimers: > + /* > + * If replication delay is enormously huge, just treat that as > + * zero and work up from there. This prevents us from acting > + * foolishly when replaying old log files. > + */ > + if (*currentDelay_ms < 0) > + *currentDelay_ms = 0; > + > > So we're treating restoring from an old backup the same as an up-to-date > standby server. If you're restoring from say a month old base backup > with WAL archive up to present day, and have max_standby_delay set to > say 5 seconds, the server will wait for that 5 seconds on each > conflicting query before killing it. Until it reaches the point in the > archive where the delay is less than INT_MAX/1000 seconds old: at that > point it switches into "oh my goodness, we've fallen badly behind, let's > try to catch up ASAP and kill any queries that get into the way" mode. > That's pretty surprising behavior, and not documented either. I propose > we simply remove the above check (fixing the rest of the code so that > you don't hit integer overflows), and always respect max_standby_delay.
Agreed. I will docuemnt the recommendation to set max_standby_delay = 0 if performing an archive recovery (and explain why). > BTW, I wonder if should warn or something if we find that the timestamps > in the archive are in the future? IOW, if either the master's or the > standby's clock is not set correctly. Something similar was just spotted by a client. You can set a recovery_target_timestamp that is before the pg_stop_recovery() timestamp and it doesn't complain. Will fix. Not sure if I like the sound of a system moaning at me about the clock settings. Perhaps just once when it starts, when we read control file. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers