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.GC.buildPackIndex, consider transactions that are in the future as infinitely old. Something like this:
Uploaded: zodb-pack- future. patch
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. GC.buildPackInd ex, consider transactions that are in the future as infinitely old. Something like this: