Fix duplicate read when point is in WAL and disk #3482
Conversation
| } | ||
| } | ||
| return c.readBuf() | ||
| } | ||
| } |
There was a problem hiding this comment.
This is the whole change. It looks larger than it really is. The code is mostly expanded out for clarity. Previously we only checked if we we had a cursor item and either no cache or the buffer was a lower timestamp than the cache. Now it checks if the timestamps are equal and drains out the cache. Draining the cache works to remove any multiple duplicates that could have been written to the WAL.
The rest of the changes are to add testing to the v1 engine. All existing testing for the engine was left in the tsdb package for now.
There was a problem hiding this comment.
Sorry, I fixed another issue in 097b025 so that the cache is read instead of the buffer.
This commit fixes an issue where two points in a series with the same timestamp can be read twice if they are in the WAL and disk. The write to the WAL should overwrite the write to the disk and the client should only see the WAL version. Fixes influxdata#3315.
|
|
||
| // Write point again. | ||
| if err := e.WritePoints([]tsdb.Point{ | ||
| tsdb.NewPoint("cpu", tsdb.Tags{}, tsdb.Fields{"value": 100}, time.Unix(0, 1)), |
There was a problem hiding this comment.
second point should have a different value, which you can then read in the test verification to ensure that the latter point is the one that was actually used when a dupe was found
|
I just checked this out and tested it and still see the same behavior. Repro steps from the CLI: |
|
I can also confirm that this isn't fixing it for me either |
Overview
This commit fixes an issue where two points in a series with the same timestamp can be read twice if they are in the WAL and disk. The write to the WAL should overwrite the write to the disk and the client should only see the WAL version.
Fixes #3315.
/cc @ccutrer @pauldix @beckettsean