|
It looks like I will need to fix this as part of enabling clustered collection scans in SBE (PM-3161). Last week I independently discovered the problem of the build-time seek embedding minRecord and maxRecord bounds into the cached plan, which causes scans to return wrong results if the same query form gets submitted again with differing bounds, and also thought the correct fix to that is to pass minRecord and maxRecord into ScanStage and do the seek at run time instead of build time (as opposed to encoding minRecord and maxRecord into the plan cache key to force a mismatch).
I found this problem when I patterened my new code implementing regular clustered collection scans on the existing oplog clustered collection scan code, not knowing at the time that the oplog scan code was known to be buggy.
I also suspect the conditions for calling the oplog scan path generateOptimizedOplogScan() in sbe_stage_builder_coll_scan.cpp generateCollScan() are not correct as they omit || csn->resumeAfterRecordId in the oplog scan builder, so this flag will not reach generateOptimizedOplogScan() in some (or maybe all) cases when it should, even though that method has code to handle it:
if (csn->minRecord || csn->maxRecord || csn->stopApplyingFilterAfterFirstMatch) { return generateOptimizedOplogScan(
|
This problem would not have manifested either currently as oplog scans had been disabled in SBE (SERVER-57365) and have not yet been re-enabled.
|