[Lalo Martins]
>>> A few days later, we realized that pack wasn't working anymore

[Tim Peters]
>> 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

Reply via email to