Message-ID: <4AC37D2D.9060400@enterprisedb.com>
Date: Wed, 30 Sep 2009 18:45:49 +0300
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Simon Riggs <simon@2ndQuadrant.com>
CC: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Hot Standby on git
References: <1253958559.4449.833.camel@ebony.2ndQuadrant>
In-Reply-To: <1253958559.4449.833.camel@ebony.2ndQuadrant>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com