I think this came up in recent discussions about the whether we get get rid of delete tombstones on non-major compactions. One of the subtasks for stripe compactions deals with this case.
On Tue, Mar 19, 2013 at 2:27 PM, Ted Yu <[email protected]> wrote: > This is also related: > > HBASE-8086 Major compact should flush memstore firstly > > On Tue, Mar 19, 2013 at 2:24 PM, Ted Yu <[email protected]> wrote: > > > Here is one related thread (on minor compaction, though) : > > > > Is it feasible to delete qualified tombstones during minor compaction? > > > > > > On Tue, Mar 19, 2013 at 1:42 PM, Jean-Daniel Cryans <[email protected] > >wrote: > > > >> Hey guys, > >> > >> I looked around a bit and couldn't find a jira directly related to > >> this. Here's an example of inconsistency in every HBase version > >> (although the shell won't let you do it in trunk): > >> > >> create 't', 'f' > >> delete 't', '1', 'f:1', 3 > >> flush 't' > >> put 't', '1', 'f:1', '1', 2 > >> scan 't' > >> major_compact 't' > >> scan 't' > >> > >> The first scan returns nothing, the second one returns the row 1. This > >> is the same when the delete is bulk loaded and then major compacted > >> (which is a more legitimate use case). > >> > >> What's the common wisdom here? Does anyone remember if we had this > >> discussion in the past? > >> > >> Thx, > >> > >> J-D > >> > > > > >
