Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id F3E5B1337C04 for ; Wed, 20 Apr 2011 12:15:26 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 60191-04 for ; Wed, 20 Apr 2011 15:15:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 24A0C133798E for ; Wed, 20 Apr 2011 12:15:08 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p3KFF6dh027150; Wed, 20 Apr 2011 11:15:07 -0400 (EDT) To: Robert Haas cc: Greg Stark , pgsql-hackers@postgresql.org Subject: Re: time-delayed standbys In-reply-to: References: <26007.1303309175@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 20 Apr 2011 11:05:43 -0400" Date: Wed, 20 Apr 2011 11:15:06 -0400 Message-ID: <27149.1303312506@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201104/1034 X-Sequence-Number: 186236 Robert Haas writes: > I am a bit concerned about the reliability of this approach. If there > is some network lag, or some lag in processing from the master, we > could easily get the idea that there is time skew between the machines > when there really isn't. And our perception of the time skew could > easily bounce around from message to message, as the lag varies. I > think it would be tremendously ironic of the two machines were > actually synchronized to the microsecond, but by trying to be clever > about it we managed to make the lag-time accurate only to within > several seconds. Well, if walreceiver concludes that there is no more than a few seconds' difference between the clocks, it'd probably be OK to take the master timestamps at face value. The problem comes when the skew gets large (compared to the configured time delay, I guess). regards, tom lane