Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VpzlV-0008IM-99 for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Dec 2013 12:16:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VpzlU-0004aS-KZ for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Dec 2013 12:16:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VpzlT-0004aE-H8 for pgsql-hackers@postgresql.org; Mon, 09 Dec 2013 12:16:43 +0000 Received: from outmail149075.authsmtp.net ([62.13.149.75]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VpzlM-0000Pt-JF for pgsql-hackers@postgresql.org; Mon, 09 Dec 2013 12:16:43 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id rB9CGYIv012281; Mon, 9 Dec 2013 12:16:34 GMT Received: from ayaki.localdomain (124-148-110-41.dyn.iinet.net.au [124.148.110.41]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB9CGQBY054983 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 12:16:30 GMT Message-ID: <52A5B499.3060008@2ndquadrant.com> Date: Mon, 09 Dec 2013 20:16:25 +0800 From: Craig Ringer Organization: 2nd Quadrant User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Robert Haas , =?ISO-8859-1?Q?Fabr=EDzio_Mell?= =?ISO-8859-1?Q?o?= CC: Christian Kruse , Pgsql Hackers Subject: Re: Time-Delayed Standbys References: <52984711.8040806@lab.ntt.co.jp> <20131203163302.GA18669@achilles.fritz.box> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Server-Quench: bd07ba7d-60cb-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZeVg0b BQteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksachtFaAxbaVxS HGQLWldEUV97WGV/ aAsfbAdZfEtKVxtr UUhXRlNNFgBqBAMA SFxsW2oFFncveHt0 bE5hEHFaXU16OxQp QkkGRGpSeGFgOzIC UUENdB5ddFUbYx9F aFV2VCIMYmBTZTQC El17DBAYFhZyEh9g Cj0MKF9XbUsPFy8x S1g5ATwpEUcUXE0A X-Authentic-SMTP: 61633235383639.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 124.148.110.41/2525 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 12/04/2013 02:46 AM, Robert Haas wrote: >> Thanks for your review Christian... > > So, I proposed this patch previously and I still think it's a good > idea, but it got voted down on the grounds that it didn't deal with > clock drift. I view that as insufficient reason to reject the > feature, but others disagreed. Unless some of those people have > changed their minds, I don't think this patch has much future here. Surely that's the operating system / VM host / sysadmin / whatever's problem? The only way to "deal with" clock drift that isn't fragile in the face of variable latency, etc, is to basically re-implement (S)NTP in order to find out what the clock difference with the remote is. If we're going to do that, why not just let the OS deal with it? It might well be worth complaining about obvious aberrations like timestamps in the local future - preferably by complaining and not actually dying. It does need to be able to cope with a *skewing* clock, but I'd be surprised if it had any issues there in the first place. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers