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. Regards, -- 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