See InListIT#testLeadingPKWithTrailingRVCSlotHole as an example query that will fail when given the /*+ RANGE_SCAN */ hint.
The issue is caused by the WhereOptimizer extracting the leading partially qualified row keys of the where clause but improperly producing splitScan start and stop rows in parallel iterators.
For example, with a where clause like:
The ScanRanges will set the scan boundaries as:
This is technically correct as the scan start/stop rows need to include the salt byte, but it means that naively intersecting the scan ranges with region boundaries such as:
Will produce the following partially incorrect splitScan boundaries:
Note that this is only a problem when the /*+ RANGE_SCAN */ hint is given. Without a hint, this query will use a skip scan, sidestepping the issue.