http://bugzilla.spamassassin.org/show_bug.cgi?id=3225
------- Additional Comments From [EMAIL PROTECTED] 2004-04-23 14:21 ------- > we may have been using the *scan* time > instead of the message's origination time Is there a problem when expiring on a specific time gets rid of too many tokens and expiring on that atime + 1 gets rid of too few? Can we just limit the number of items to be expired and select the ones to purge at random if the atime can't come up with a good number? Moving the atime discussion back here from sa-dev: Someone suggested dropping high bits. The problem with that is it implies that the origin of the atime units (i.e. what time is reperesented by atime==0) has to be changed to be relative to the times in the db. How about this: Make the time units and the origin configuration options. The size of atime would be defined in the schema. The current behavior would be a granularity of 1 second, an origin of Jan 1, 1970 and a schema that makes atime a 32 bit unsigned int, which will last for another 33 years or so. Setting the granularity to 2 hours and an origin of Jan 1, 2004 with 16 bit unsigned int will allow for 15 years before anything has to be done. Now here is an interesting one: A granularity of 8 minutes and using 16 bit ints will overflow after about one year. If it is acceptible to go through the entire db once a year and adjust all atimes with a new origin that makes the oldest equal to 0, that would work. If we have a "super-expiry" operation that resets the origin of all the atimes, we could leave it up to configuration options to specify atime scale, origin, word size, and frequency of super-expiry. That would allow a lower volume site to configure for 2 byte atimes that only have to be checked once a day, while a very high volume site with a global database could check more often and decide to either configure for a larger db that uses 32 bit ints or run a "super-expiry" more often. I don't see much extra cost for the extra flexibility. Comments anyone? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
