-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expiry works only during runtime and is lost on shrink #112
Comments
actually it's a bug about the db reconstruction, not only shrink |
@tidwall please look into this issue. |
I looked into this issue. There are two problems. First, when loading a database from disk, entries with an expired timestamp may still find their way to the in-memory database if there was a previous (non-expired) entry that was already added. Second, iterators do not check each item that may have been expired before returning it to the caller. The PR by @Sora233 sorta fixes the problem by always reinserting every item. This works for The correct fix would be to force delete entries on load when those entries are expired, and then also check when items have expired during iteration. |
I just pushed a fix that addresses the problem. |
Thank you @tidwall ! |
I think I can close the issue as resolved. |
Version: v1.3.0
If I add key first without expiry and then re-set it with expiry, but the expiry is not concluded during runtime, they key is never expired and on shrinking expiry is lost. To reproduce it:
Run this code:
The data.db will look like this:
After more than 5 seconds, run this code:
It will print:
The data.db file looks like this:
I guess the expiry is not set when reconstructing the state from the log if there were previous versions of the same key without expiry.
The text was updated successfully, but these errors were encountered: