-
Notifications
You must be signed in to change notification settings - Fork 3k
Core: Don't clear snapshot log when intermediate snapshots are detected #5568
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
Conversation
| // if history is [(t1, s1), (t2, s2), (t3, s3)] and s2 is removed, the history cannot be | ||
| // [(t1, s1), (t3, s3)] because it appears that s3 was current during the time between t2 | ||
| // and t3 when in fact s2 was the current snapshot. | ||
| newSnapshotLog.clear(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This problem was introduced in #3664. The original code that this comment applies to cleared the log when it encountered a snapshot that has been expired and removed. That's the correct behavior.
The problem is that I combined that behavior with the check to suppress intermediate snapshots in a transaction. We should suppress those snapshots in the log, but we don't need to clear the log. Here's what I think should happen instead:
if (snapshotsById.containsKey(snapshotId)) {
if (!intermediateSnapshotIds.contains(snapshotId)) {
// copy the log entries that are still valid
newSnapshotLog.add(logEntry);
}
} else {
// any invalid entry causes the history before it to be removed. otherwise, there could be
// history gaps that cause time-travel queries to produce incorrect results. for example,
// if history is [(t1, s1), (t2, s2), (t3, s3)] and s2 is removed, the history cannot be
// [(t1, s1), (t3, s3)] because it appears that s3 was current during the time between t2
// and t3 when in fact s2 was the current snapshot.
newSnapshotLog.clear();
}There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯 This looks correct to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes total sense, thanks
eadf13b to
61da89b
Compare
kbendick
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM once tests pass.
Considering that this change reverts an earlier refactor, I don't think that additional manual testing is necessarily needed.
| files(FILE_A, FILE_B), | ||
| statuses(Status.ADDED, Status.ADDED)); | ||
|
|
||
| org.assertj.core.api.Assertions.assertThat(table.history()).containsAll(initialHistory); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might consider asserting on the entire history that should be there -- which should be the initial history + the one entry post txn.commitTransaction().
|
Thanks for fixing this, @nastra! |
fixes #5442