RE: [ZODB-Dev] Re: extreme clock skew
[Lalo Martins] >>> It considers timestamps in the future as infinitely old; so in a >>> hypotetical database where all transactions are in the future, it would >>> copy only "reachable" transactions. [Tim Peters] >> Offhand that makes sense. It would be interesting to figure out why >> it didn't pack anything, but don't have spare time for that ... [Lalo] > It is in the collector, in case you want to check. > http://www.zope.org/Collectors/Zope/1861 Hmm. Didn't you say this didn't work for you? If so, the Collector comments should say so up front. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Re: extreme clock skew
[Lalo Martins] >>> A few days later, we realized that pack wasn't working anymore [Tim Peters] >> What does "wasn't working" mean? ... [Lalo] > sorry for not giving detail here, I figured it would be obvious. > > During the clock skew, the database was packed at least once. Believe me when I say that wasn't obvious ;-) > So after time returned to normal, packing refuses to run, claiming "the > database was already packed at a later time". That makes sense. >> Which version of ZODB are you using? ZODB always intended that tids be >> monotonically increasing, but some older versions have known bugs where >> that can be violated. > That's a Zope 2.7.3; I'm pretty sure it doesn't have these bugs (judging > from the research I did before posting). That's ZODB 3.2.4, then. 3.2.9 is current. The specific bug I had in mind was collector issue 1327, and that was repaired in 3.2.3. ... >> You didn't tell us anything about what your packing fix did ... > It considers timestamps in the future as infinitely old; so in a > hypotetical database where all transactions are in the future, it would > copy only "reachable" transactions. Offhand that makes sense. It would be interesting to figure out why it didn't pack anything, but don't have spare time for that ... ... >> In fact, while I haven't tried this, I _suspect_ that changing [to] >> >> self.tpc_begin(transaction, None, transaction.status) >> >> [in copyTransactionsFrom() would suffice] > this, however, I didn't find by myself; thanks a lot :-) Do let us know whether it worked! ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Re: extreme clock skew
Lalo Martins wrote: So you've ignored critical-level log messages for a few weeks? I'm not trying to pick a fight , I'm trying to understand how you got into this. A critical-level log msg is the most severe thing we can do without plain refusing to run at all. It does. And we did. Don't worry, I already had that fight :-) We have a procedure in place for reviewing logs, so if it managed to let this one slip trough the cracks for weeks, it's clearly insufficient. I'm going to be reviewing it (the procedure) after I'm out of this mess. Can I take the opportunity to recommend MailingLogger. MailingLogger has saved my ass in exactly this kind of situation many many times ;-) cheers, Chris - who doesn't like grepping log files and much prefers to have just the important bits mailed direct to him ;-) -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
