Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of sergey@hortonworks.com
 designates 74.125.82.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMUu0w8b1XUHKNStdySkSBJL30juyMuVre5kmrYe5L_QbGKiag@mail.gmail.com>
References: 
 <CAGpTDNfxQqTcm82_0qQpQzOtajH=XLSan9fF6txOXKHkeVgwTw@mail.gmail.com>
	<CALte62zNz_=Aq2Y+O2+a521MUesBWSqMuVLVcRSrKTf6JFKJvA@mail.gmail.com>
	<CALte62wE6SNx4dh0JTdODNY9+nmL6Y+nsoHpqJvZjSkHUWqRKw@mail.gmail.com>
	<CAMUu0w8b1XUHKNStdySkSBJL30juyMuVre5kmrYe5L_QbGKiag@mail.gmail.com>
Date: Tue, 19 Mar 2013 18:36:39 -0700
Message-ID: 
 <CAHXxaiB=CL+Rkj=XutMRZ-rsyfgOfbmuiLubMkCXjWeD_j2wZg@mail.gmail.com>
Subject: Re: Consistency issue when a Put is in the memstore but a more recent
 Delete is cleaned in a major compaction
From: Sergey Shelukhin <sergey@hortonworks.com>
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=001a11c34e9ee65cc104d8514067

--001a11c34e9ee65cc104d8514067
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=F6ztutar <enis.soz@gmail.com> wrote=
:

> I think this came up in recent discussions about the whether we get get r=
id
> 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 <yuzhihong@gmail.com> wrote:
>
> > This is also related:
> >
> > HBASE-8086 Major compact should flush memstore firstly
> >
> > On Tue, Mar 19, 2013 at 2:24 PM, Ted Yu <yuzhihong@gmail.com> 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 <
> jdcryans@apache.org
> > >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. Th=
is
> > >> 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
> > >>
> > >
> > >
> >
>

--001a11c34e9ee65cc104d8514067--