Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 16555200CAE for ; Tue, 6 Jun 2017 18:41:24 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 14C42160BB7; Tue, 6 Jun 2017 16:41:24 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 62350160BC6 for ; Tue, 6 Jun 2017 18:41:23 +0200 (CEST) Received: (qmail 48982 invoked by uid 500); 6 Jun 2017 16:41:22 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 48858 invoked by uid 99); 6 Jun 2017 16:41:22 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jun 2017 16:41:22 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 2E97BCAFB8 for ; Tue, 6 Jun 2017 16:41:22 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id KXYyujA2bf2i for ; Tue, 6 Jun 2017 16:41:21 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 2E72C61051 for ; Tue, 6 Jun 2017 16:41:20 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 78625E0DF5 for ; Tue, 6 Jun 2017 16:41:19 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id A2D6921E2C for ; Tue, 6 Jun 2017 16:41:18 +0000 (UTC) Date: Tue, 6 Jun 2017 16:41:18 +0000 (UTC) From: "Dave Latham (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-8770) deletes and puts with the same ts should be resolved according to mvcc/seqNum MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 06 Jun 2017 16:41:24 -0000 [ https://issues.apache.org/jira/browse/HBASE-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039224#comment-16039224 ] Dave Latham commented on HBASE-8770: ------------------------------------ > We will remove mvcc in HFile in minor compaction (to save capacity) and delete/put will have same mvcc if they are in one same file. I think that would be OK so long as we first order by seq id, then order Put ahead of Delete for the same seq id. If we're compacting to an HFile, and the Put has higher seq id than the Delete, write them both, and the Put will stay visible. If the Delete has a higher seq id than the Put, then just drop the Put as it should never be visible. Would that work or am I missing something? However, if we do switch to always keeping the seq id around, then the point is moot. Except for the next case of an atomic RowMutation with Put and Delete having the same seq id. Then we have to make a call ont he semantic. I think it's more useful to favor the Put over the Delete (would solve HBASE-8626 also). > deletes and puts with the same ts should be resolved according to mvcc/seqNum > ----------------------------------------------------------------------------- > > Key: HBASE-8770 > URL: https://issues.apache.org/jira/browse/HBASE-8770 > Project: HBase > Issue Type: Brainstorming > Reporter: Sergey Shelukhin > Priority: Critical > > This came up during HBASE-8721. Puts with the same ts are resolved by seqNum. It's not clear why deletes with the same ts as a put should always mask the put, rather than also being resolve by seqNum. > What do you think? -- This message was sent by Atlassian JIRA (v6.3.15#6346)