Yes, it is the same window of opportunity that was mentioned in some other JIRAs and threads (see also HBASE-7902<https://issues.apache.org/jira/browse/HBASE-7902>) and would have been made wider by dropping deletes during minor compactions :) If flush is done before major compaction, the window will just be narrowed, not eliminated, because you could write data during major compaction...
On Tue, Mar 19, 2013 at 2:32 PM, Enis Söztutar <[email protected]> wrote: > 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 > > >> > > > > > > > > >
