[
https://issues.apache.org/jira/browse/HBASE-21596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wellington Chevreuil updated HBASE-21596:
-----------------------------------------
Description:
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.
was:
Originally tested with HBase Shell delete command, but it's also reproducible
with Client API Delete operation.
> 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
(v7.6.3#76005)
