Skip site navigation (1) Skip section navigation (2)

Re: Hot Standby on git

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot Standby on git
Date: 2009-09-30 15:45:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2009-09-30 15:50:25
Subject: Re: TODO item: Allow more complex user/database default GUC settings
Previous:From: Tom LaneDate: 2009-09-30 15:36:40
Subject: Re: CommitFest 2009-09, two weeks on

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group