setex silent data loss when using unix time for expiration value about redis

[GoogleCodeExporter]

Hello, this is a bug indeed and it is due to an integer overflow that only 
happens in 32 bit builds.

However there is no perfect fix as time_t is 32 bit in 32 bit archs. What I'm 
probably going to do is to set it to the max unix time when it would overflow, 
so that those keys will expire in 2036. But this somewhat violates the 
semantics as you set a given expire and read a different one using the TTL 
command... better to think a bit more about it :) But this is likely the best 
fix for 32 bit.

Thanks for reporting.

Salvatore

Original comment by [email protected] on 12 Sep 2011 at 11:33

[GoogleCodeExporter]

Original comment by [email protected] on 12 Sep 2011 at 11:34

• Changed state: Accepted

[GoogleCodeExporter]

Redis already appears to reject larger expiration times (e.g. anything over 
2**31 on my system). I think that rejecting values that would overflow a 32-bit 
value after being added to the current time would be an acceptable solution.

An argument may be made that redis should not fall apart around year 2037 and 
should support 64-bit times on all architectures. This argument is somewhat 
orthogonal to the bug here - redis should never overflow the time value; if on 
a 64-bit system I specify 2**64-1000 as the expiration value it should either 
be rejected or treated correctly as a future value, instead of being wrapped 
around at 2**64.

Due to redis requesting a delta for the expiration time, people who want to 
specify a value far in the future are likely to use something like "10 years 
from now" as opposed to "January 1, 2020". As we get closer to 2037 having 
32-bit values for times will begin to affect more users.

Requiring a 64-bit redis for proper time handling has its own drawbacks. One is 
increased memory consumption of 64-bit redis, which is addressed in the faq. 
Another one is continuing existence of low-spec servers with under 4 gb of ram, 
where running a 64-bit operating system makes little or no sense.

In my case there was a bug in the code and I actually wanted a reasonable 
expiration time, but due to porting the code from memcached it misspecified the 
delta as a timestamp.

Original comment by [email protected] on 13 Sep 2011 at 2:10

[GoogleCodeExporter]

Thanks for the additional details, I moved the issue to the new issue system at 
github so that we can address it ASAP. Cheers.

Original comment by [email protected] on 20 Sep 2011 at 10:19