[
https://issues.apache.org/jira/browse/HBASE-21596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931241#comment-16931241
]
HBase QA commented on HBASE-21596:
----------------------------------
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 7s{color}
| {color:red} HBASE-21596 does not apply to master. Rebase required? Wrong
Branch? See
https://yetus.apache.org/documentation/in-progress/precommit-patchnames for
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-21596 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954788/HBASE-21596-master.003.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/905/console |
| versions | git=2.17.1 |
| Powered by | Apache Yetus 0.11.0 https://yetus.apache.org |
This message was automatically generated.
> 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
> Reporter: Wellington Chevreuil
> Assignee: Wellington Chevreuil
> Priority: Minor
> 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.2#803003)
