[ZODB-Dev] Summertime -> Wintertime harmful?

[Andreas Jung]

--On 30. Oktober 2005 22:17:44 -0500 Tim Peters <tim at zope.com> wrote:

>>
>> Second, time-stamp skew doesn't lead to inconsistency.
>
> Fleshing out a bit, ZODB uses time.gmtime() as a starting point, not
> necessarily as its final timestamp.  When generating a new tid, if
> time.gmtime() is <= the last tid generated, the last tid is incremented
> instead (by a small number of nanoseconds).  So tids are always strictly
> increasing, no matter how crazy the system clock gets.  Older versions of
> ZODB had some obscure bugs in extreme cases of clock insanity, under which
> it was possible for tids not to always increase, but no bugs of that sort
> should remain.
>
> It's still a bad idea to let the system clock be insane, and upon opening
> a FileStorage ZODB logs a warning message if time appears to have "gone
> backwards" at all, and a critical message if it appears to have gone
> backwards by more than 30 minutes (but note that if the system clock "went
> forward" in time, ZODB has no way to guess that).  tids in current ZODBs
> will still be increasing, but there's a downside:  there are a _lot_ of
> "small number of nanoseconds" in a second, so for as long as ZODB remains
> in "increment the last tid by a small number of nanoseconds, because
> time.gmtime() is crazy" mode, successive transactions will get timestamps
> only a few nanoseconds apart.  This can wreak havoc with, e.g., forensic
> analysis of database dumps, and with sane packing (if the last year's
> worth of transactions all appear to have occurred in the same 1-second
> interval, good luck guessing a useful pack-time argument).

Thanks for this detailed answer!

Andreas



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zodb-dev/attachments/20051031/a4032d56/attachment.bin