Clock skew and packing
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| ZODB |
Low
|
Unassigned |
Bug Description
If you have transactions with a timestamp in the future (probably due to clock skew), they will never be packed away, at least not until you get to that date again.
If you compound that with an application-level bug that for some reason causes the database file to grow too fast, then you'll have a really huge and slow server and no easy way to fix it.
Proposed solution: on ZODB.fspack.
Lalo Martins (lalo.martins) wrote : | #0 |
Tim Peters (tim-one) wrote : | #1 |
Thomas Güttler (hv-tbz-pariv) wrote : | #2 |
Uploaded: BaseStorage_
I had the problem, too. The clock was set to the year 2009 for very short, but now all new tids are from 2009.
Tim Peter suggested, that you can solve the problem by doing
a storage.
See bottom of:
http://
This is a small path to BaseStorage with gives the method copyTransaction
If you use the method once, all tids are reset to the current time.
This means, you don't need the patch zodb-pack-
affects: | zope2 → zodb |
Jim Fulton (jim-zope) wrote : | #3 |
A better patch would set tids > now to about now, making sure their order is preserved.
A better patch would also have a test. :)
Doing this as part of pack has the operational advantage that it doesn't require down time.
There's more about this patch on the zodb-dev list:
http:// mail.zope. org/pipermail/ zodb-dev/ 2005-September/ 009248. html
If the patch works, it might be nice to have an option to explicitly ask for it, but I wouldn't want to assume that "time in the future means infinitely old" by default.
In all, if I had time to look at this, I'd rather spend it on automating a way to force timestamps in badly skewed databases back to sane times.