[
https://issues.apache.org/jira/browse/HBASE-21596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17154575#comment-17154575
]
Hudson commented on HBASE-21596:
--------------------------------
Results for branch master
[build #1781 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/1781/]: (x)
*{color:red}-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/1781/General_20Nightly_20Build_20Report/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/1781/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/1781/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)
