Re: Time-Delayed Standbys

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Christian Kruse <christian(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Time-Delayed Standbys
Date: 2013-12-05 09:57:50
Message-ID: CA+U5nM+hbLwc_oUeYBYZjUPc_fM5=LX0VO1Op1fXPycLFe0vfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5 December 2013 08:51, Magnus Hagander <magnus(at)hagander(dot)net> wrote:

> Not recalling the older thread, but it seems the "breaks on clock drift", I
> think we can fairly easily make that situation "good enough". Just have
> IDENTIFY_SYSTEM return the current timestamp on the master, and refuse to
> start if the time difference is too great. Yes, that doesn't catch the case
> when the machines are in perfect sync when they start up and drift *later*,
> but it will catch the most common cases I bet. But I think that's good
> enough that we can accept the feature, given that *most* people will have
> ntp, and that it's a very useful feature for those people. But we could help
> people who run into it because of a simple config error..
>
> Or maybe the suggested patch already does this, in which case ignore that
> part :)

I think the very nature of *this* feature is that it doesnt *require*
the clocks to be exactly in sync, even though that is the basis for
measurement.

The setting of this parameter for sane usage would be minimum 5 mins,
but more likely 30 mins, 1 hour or more.

In that case, a few seconds drift either way makes no real difference
to this feature.

So IMHO, without prejudice to other features that may be more
critically reliant on time synchronisation, we are OK to proceed with
this specific feature.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-12-05 10:03:35 Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Andres Freund 2013-12-05 09:56:41 Re: same-address mappings vs. relative pointers