>>> A few days later, we realized that pack wasn't working anymore
>> What does "wasn't working" mean? ...
> 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:
ZODB-Dev mailing list - ZODB-Dev@zope.org