[ https://issues.apache.org/jira/browse/PHOENIX-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780504#comment-17780504 ]
ASF GitHub Bot commented on PHOENIX-7004: ----------------------------------------- virajjasani commented on PR #1724: URL: https://github.com/apache/phoenix/pull/1724#issuecomment-1783362587 > @virajjasani Thinking what changed from this PR #1697 ? this is the main diff: ``` public static void verifyKeyInScanRange(ImmutableBytesWritable ptr, Scan scan, Tuple tuple) throws ResultSetOutOfScanRangeException { if ((tuple.size() == 1 && tuple.getValue(SINGLE_COLUMN_FAMILY, SINGLE_COLUMN) != null) || (tuple.size() == 1 && tuple.getValue(OFFSET_FAMILY, OFFSET_COLUMN) != null) || isDummy(tuple)) { return; } if (isLocalIndex(scan)) { verifyScanRanges(ptr, scan, scan.getAttribute(SCAN_START_ROW_SUFFIX), scan.getAttribute(SCAN_STOP_ROW_SUFFIX)); } else { try { verifyScanRanges(ptr, scan, scan.getStartRow(), scan.getStopRow()); } catch (ResultSetOutOfScanRangeException e) { // required for Salt Buckets scan boundary changes verifyScanRanges(ptr, scan, scan.getAttribute(SCAN_ACTUAL_START_ROW), scan.getStopRow()); } } } ``` Basically, we need to take care of these cases: - Aggregate scan results - Offset based results - Dummy cell - Local index scan boundary changes - Salt table scan boundary changes But anyways, fixing group by aggregator cases is required at server side for data integrity issues. I just wanted to exercise on how many cases we need to handle here. I am sure local index and salt table scan boundary changes might also need some careful considerations at server side. FYI @Divneet18, you can incorporate the changes and write a test with coproc that can return incorrect result so that we can test scan boundaries negative results. > Validate the result returned by phoenix query is within scan range, if > provided. > -------------------------------------------------------------------------------- > > Key: PHOENIX-7004 > URL: https://issues.apache.org/jira/browse/PHOENIX-7004 > Project: Phoenix > Issue Type: Bug > Reporter: Rushabh Shah > Assignee: Divneet Kaur > Priority: Major > > Encountered an issue in production cluster where the range scan query > returned incorrect results (result were out of range). > We were running hbck repair operations on the same table. Therefore there > were region holes and region overlaps exactly at the same time while the > query was running. Already created PHOENIX-7003 to harden inconsistency > checks. > In general, we should validate that the results returned back to customer > (via PhoenixResultSet#next) is always within the scan boundaries if provided. -- This message was sent by Atlassian Jira (v8.20.10#820010)