lhofhansl commented on a change in pull request #629: PHOENIX-5559 Fix
remaining issues with Long viewIndexIds.
URL: https://github.com/apache/phoenix/pull/629#discussion_r345536518
##########
File path:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/BaseScannerRegionObserver.java
##########
@@ -178,8 +178,11 @@ private static void throwIfScanOutOfRegion(Scan scan,
Region region) throws DoNo
byte[] expectedUpperRegionKey =
scan.getAttribute(EXPECTED_UPPER_REGION_KEY) == null ?
scan.getStopRow() : scan
.getAttribute(EXPECTED_UPPER_REGION_KEY);
- isStaleRegionBoundaries = expectedUpperRegionKey != null &&
- Bytes.compareTo(upperExclusiveRegionKey,
expectedUpperRegionKey) != 0;
+
+ byte[] actualStartRow = scan.getAttribute(SCAN_ACTUAL_START_ROW);
+ isStaleRegionBoundaries = (expectedUpperRegionKey != null &&
+ Bytes.compareTo(upperExclusiveRegionKey,
expectedUpperRegionKey) != 0) ||
+ (actualStartRow != null && Bytes.compareTo(actualStartRow,
lowerInclusiveRegionKey) < 0);
} else {
isStaleRegionBoundaries = Bytes.compareTo(lowerInclusiveScanKey,
lowerInclusiveRegionKey) < 0 ||
Review comment:
This is because for local indexes we cannot (ever) proceed when the region
was split, we have to restart, since we cannot exactly know where the index
keys were split to, they sort differently than the main table's keys.
It's not enough that the new scan is fully "contained" in the new region. Is
that end "old" scan boundaries are contained on the lower side and exact on the
upper side.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
