[ https://issues.apache.org/jira/browse/HBASE-21596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155508#comment-17155508 ]
Hudson commented on HBASE-21596: -------------------------------- Results for branch master [build #1782 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/1782/]: (/) *{color:green}+1 overall{color}* ---- details (if available): (/) {color:green}+1 general checks{color} -- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/master/1782/General_20Nightly_20Build_20Report/] (x) {color:red}-1 jdk8 hadoop2 checks{color} -- For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/master/1663//JDK8_Nightly_Build_Report_(Hadoop2)/] (/) {color:green}+1 jdk8 hadoop3 checks{color} -- For more information [see jdk8 (hadoop3) report|https://builds.apache.org/job/HBase%20Nightly/job/master/1782/JDK8_20Nightly_20Build_20Report_20_28Hadoop3_29/] (/) {color:green}+1 jdk11 hadoop3 checks{color} -- For more information [see jdk11 report|https://builds.apache.org/job/HBase%20Nightly/job/master/1782/JDK11_20Nightly_20Build_20Report_20_28Hadoop3_29/] (/) {color:green}+1 source release artifact{color} -- See build output for details. (/) {color:green}+1 client integration test{color} > Delete for a specific cell version can bring back versions above VERSIONS > limit > ------------------------------------------------------------------------------- > > Key: HBASE-21596 > URL: https://issues.apache.org/jira/browse/HBASE-21596 > Project: HBase > Issue Type: Bug > Affects Versions: 3.0.0-alpha-1 > Reporter: Wellington Chevreuil > Assignee: Wellington Chevreuil > Priority: Minor > Fix For: 3.0.0-alpha-1 > > Attachments: HBASE-21596-master.001.patch, > HBASE-21596-master.002.patch, HBASE-21596-master.003.patch, initial-patch.txt > > > Originally tested with HBase Shell delete command, but it's also reproducible > with Client API Delete operation. > The problem is that the memstore scan filter logic for versions only counts > the amount of cells it has read so far, then once the VERSIONS limit has been > reached, it just skips the remaining cells. If a delete marker is inserted on > a given cell version, that cell will not be accounted, then oldest versions > that should had disappeared will now pop up on the scan results. > Example, for a cell from a CF with max versions of 3, that has 4 versions T1, > T2, T3 and T4, scan correctly shows T4, T3 and T2. If a delete is triggered > for any for these 3 versions, say T3, scan now will show: T4, T2 and T1, but > T1 was supposed to be gone by the time T4 was added. -- This message was sent by Atlassian Jira (v8.3.4#803005)