Hi Jan,

Thanks for your response. In my use case with Linux platform, the time will
shift a large interval according to the NTP protocol design. After first
time sync, the following sync would be relatively small and we can ignore in
slony.

I think the issue is not in slony tables for replication but in slon
schedule thread itself during waiting and checking. The schedule thread will
not response to any event if there has a big time shift backward.

In above case, if there has any time monitor mechanism to check there has a
big time change, then notify schedule thread to refresh its memory cache.
Restart slon process also work in this case but might not that graceful.

Thanks,
Jason


On Tue, Nov 9, 2010 at 11:03 PM, Jan Wieck <JanWieck at yahoo.com> wrote:

> On 11/1/2010 11:43 AM, Jason Chen wrote:
>
>> Thanks, Steve. So looks like the only solution is we have to restart
>> slon service when NTP causes time shift. However, if some events are
>> generated with the timestamp in the future, after slon service restart,
>> will these events be handled or still need to wait until that time since
>> the events timestamp don't changes?
>>
>
> Note that on Windows NTP cannot skew the clock and is forced to act via
> step adjustment. Under normal conditions, this should only set the clock
> forward/backward by a second or so. Jumping suddenly 7 hours is far from
> normal.
>
> Aside from that, slony doesn't use any of the timestamps in its tables for
> replication purposes. They are purely for outside monitoring. After
> restarting your slon processes replication will work just fine.
>
>
> Jan
>
>
>
>>
>> On Mon, Nov 1, 2010 at 11:00 PM, Steve Singer <ssinger at ca.afilias.info
>> <mailto:ssinger at ca.afilias.info>> wrote:
>>
>>    On 10-11-01 12:53 AM, Jason Chen wrote:
>>
>>        Hi Steve,
>>
>>        After detail check log/core dump and sl_event table, I have
>>        figured out
>>        the root cause which is the time change issue.
>>
>>        During the master node configuration, time has changed after
>>        configure
>>        slon service. I am configuring VM machine in a ESX host which
>>        time is
>>        earlier 7 hours than NTP server which VM machine is using after
>>        configuration. This will cause slon sched thread continuously
>>        check and
>>        wait for 7 hours. The simple workaround here is to restart slon
>>        service
>>        to refresh the time in slon sched thread.
>>
>>        This might bring a new requirement on slony. Do we have any kind of
>>        mechanism to handle time change other than restart slon service?
>>        Consider one scenario, after slon service configured
>>        successfully and
>>        there have many SYNC events generated, then user configures a new
>>        external NTP server which might has several days before the current
>>        time. This will cause all previous un-confirmed SYNC events
>>        cannot be
>>        synced until time has caught up.
>>
>>        Could you share your insight on this potential issue?
>>
>>
>>    The slony manual recommends that your slon nodes be synchronized
>>    with NTP.  If the VM has issues getting the correct time from the VM
>>    host then you might be better running NTP on the VM host.
>>
>>    If your going to be time-traveling your servers then you should
>>    restart slon in between.
>>
>>
>>
>>
>>        Thanks,
>>        Jason
>>
>>
>>
>>
>> _______________________________________________
>> Slony1-hackers mailing list
>> Slony1-hackers at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-hackers
>>
>
>
> --
> Anyone who trades liberty for security deserves neither
> liberty nor security. -- Benjamin Franklin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-hackers/attachments/20101110/daae02a6/attachment.htm