On Thu, Dec 5, 2013 at 7:57 AM, Simon Riggs <si...@2ndquadrant.com> wrote:

> On 5 December 2013 08:51, Magnus Hagander <mag...@hagander.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.
Hi all,

I saw the comments of all of you. I'm a few busy with some customers issues
(has been a crazy week), but I'll reply and/or fix your suggestions later.

Thanks for all review and sorry to delay in reply.


Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello

Reply via email to