> 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