Botond Dénes
Botond Dénes
> During the development of this patch I realized an issue that isn't linked to this patch, but to Rust as a whole - the behavior on OOM errors. Stable...
I'll have a look.
``` (gdb) bt #0 0x00007f034308c2a2 in raise () from /opt/scylladb/libreloc/libc.so.6 #1 0x00007f0343075950 in abort () from /opt/scylladb/libreloc/libc.so.6 #2 0x000000000178b4d9 in flat_mutation_reader_v2::~flat_mutation_reader_v2 (this=0x603008b59680) at flat_mutation_reader.cc:1808 #3 0x00000000011eb108 in std::destroy_at (__location=0x603008b59680) at...
We should backport 9ada63a9cb to mitigate these kinds of aborts. The alternative is to litter the code with try-catches, but that is going to be a game of whack-a-mole.
No, we will soon release the next 5.0.x, (I think it is 5.0.4), which should make this go away. Note that this is just a symptom, the root cause will...
(waiting a bit for other reviewers to have a chance for objecting before queuing)
New in v2: * Rebased. * Remove unnecessary `valid &=` assignments, simple `valid = ` is enough. * Don't write to `_current_tombstone` when there is no update.
New in v3: * Use `[[fallthrough]]` instead of comment. * Check for partition-region instead of for clustering key (not all clustering elements will have a key).
> The only material comment left is about the remaining `valid &=` logic. Ah, I see now I forgot about one spot. Will fix.
New in v4: * Removed forgotten instances of `valid &=`.