mirror of
https://github.com/scylladb/scylladb.git
synced 2026-04-23 18:10:39 +00:00
6a3872b355
Our sstables::mutation_reader has a specialization in which start and end ranges are passed as futures. That is needed because we may have to read the index file for those. This works well under the assumption that every time a mutation_reader will be created it will be used, since whoever is using it will surely keep the state of the reader alive. However, that assumption is no longer true - for a while. We use a reader interface for reading everything from mutations and sstables to cache entries, and when we create an sstable mutation_reader, that does not mean we'll use it. In fact we won't, if the read can be serviced first by a higher level entity. If that happens to be the case, the reader will be destructed. However, since it may take more time than that for the start and end futures to resolve, by the time they are resolved the state of the mutation reader will no longer be valid. The proposed fix for that is to only resolve the future inside mutation_reader's read() function. If that function is called, we can have a reasonable expectation that the caller object is being kept alive. A second way to fix this would be to force the mutation reader to be kept alive by transforming it into a shared pointer and acquiring a reference to itself. However, because the reader may turn out not to be used, the delayed read actually has the advantage of not even reading anything from the disk if there is no need for it. Also, because sstables can be compacted, we can't guarantee that the sst object itself , used in the resolution of start and end can be alive and that has the same problem. If we delay the calling of those, we will also solve a similar problem. We assume here that the outter reader is keeping the SSTable object alive. I must note that I have not reproduced this problem. What goes above is the result of the analysis we have made in #1036. That being the case, a thorough review is appreciated. Fixes #1036 Signed-off-by: Glauber Costa <glauber@scylladb.com> Message-Id: <a7e4e722f76774d0b1f263d86c973061fb7fe2f2.1458135770.git.glauber@scylladb.com>