[GitHub] [phoenix] lhofhansl commented on a change in pull request #629: PHOENIX-5559 Fix remaining issues with Long viewIndexIds.

[GitBox <gi...@apache.org>]

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_r345448898
 
 

 ##########
 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;
+
 
 Review comment:
   The following is the tricky part. Previous in order to detect a stale region boundary cache we only looked at the upper region bound. That work fine as long as do not have an open scanner that has already reached the upper half of the region when we split. When the scan restarts after the split finishes, the scan restarts in the new upper daugther region and the upper might be the same (it definitely is when this was the last region of the table).
   
   That always was a problem but since we're starting with larger number of the viewIndexId this is just more likely. My solution is to use the Scan's expected start key and compare that. For everything I tested that does the right thing.

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services