Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 62E281337B68 for ; Wed, 20 Apr 2011 08:43:44 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 41698-06 for ; Wed, 20 Apr 2011 11:43:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mail.postgresql.org (Postfix) with ESMTP id E35F31337BB7 for ; Wed, 20 Apr 2011 08:43:36 -0300 (ADT) Received: by wwk4 with SMTP id 4so3965425wwk.1 for ; Wed, 20 Apr 2011 04:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=uWkvzrtqwRw/VOJkgf+c/LjFLSLNc7oQtA5ca0KfWag=; b=OrPRABP7ulriWheYlqwH6PwS6kUGqrNcKKZ4i1l2FoftLBLuunoFmeCr2i7t4LD6Fx RKQ8BlRBoeXuZNmYdUP3ZRSJ9HpwvEWLOk7Hc+uSEp6a4ZQZvf7ih/GFkxHDFpv5TIM0 yYhWCakv620Xs9wQNX0coQ+yH0+I8myK8oZmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=rgYK3eMv6C1dELx/mmJAgT3FZudd6XrlebD2H+w1ukE3zh72jVUrUxceFZqF2YilSW AAXdA9VZpuvRVlIg3P3LEwZ121wAAyhS9o7gVyfZ9UOjlrKjJqVeuhTjbXzdP3Gb3y3O 4zWGJ/7LhC1WeHWEpcxTeEIDIpRkjV7S3h4hY= Received: by 10.227.196.208 with SMTP id eh16mr7658298wbb.224.1303299816141; Wed, 20 Apr 2011 04:43:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.173.197 with HTTP; Wed, 20 Apr 2011 04:42:56 -0700 (PDT) In-Reply-To: References: From: Greg Stark Date: Wed, 20 Apr 2011 12:42:56 +0100 X-Google-Sender-Auth: 7wo61um-bTZgig8tdU8zHjrOivU Message-ID: Subject: Re: time-delayed standbys To: Robert Haas Cc: pgsql-hackers@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.898 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, RFC_ABUSE_POST=0.001 X-Spam-Level: X-Archive-Number: 201104/1006 X-Sequence-Number: 186208 On Wed, Apr 20, 2011 at 12:24 PM, Greg Stark wrote: > I haven't read the patch but are you delaying delivering the log or > delaying replaying it? I think you actually want the latter so in case > of a real failure you can choose between replaying the last 5 minutes > and recovering everything or intentionally dropping that history if > the failure was caused by an application problem. > Ok, so I read the patch. That wasn't so hard. You did implement it the way I described so great. However you did it by comparing the server timestamp and the slave timestamp. I think we should avoid that. Synchronizing clocks is a surprisingly hard problem and it would really be great if the whole system kept working if the clocks were out of sync. I don't think that's impossible, though it's a bit inconvenient. We would need to keep track of the most recent timestamp received from the master and pause recovery if we reach recovery on a record that's less than five minutes older than that record. This means we're comparing only master timestamps to each other. It does mean if the log transfer lags then recovery will lag unnecessarily. And it means the process of receiving logs is complicated by having to keep track of this timestamp. -- greg