From issues-return-4620-archive-asf-public=cust-asf.ponee.io@phoenix.apache.org Tue Feb 12 18:58:05 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 94E33180675 for ; Tue, 12 Feb 2019 19:58:04 +0100 (CET) Received: (qmail 99065 invoked by uid 500); 12 Feb 2019 18:58:03 -0000 Mailing-List: contact issues-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list issues@phoenix.apache.org Received: (qmail 99056 invoked by uid 99); 12 Feb 2019 18:58:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Feb 2019 18:58:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 5E3A8CB872 for ; Tue, 12 Feb 2019 18:58:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -109.501 X-Spam-Level: X-Spam-Status: No, score=-109.501 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id X0o59Oltuha8 for ; Tue, 12 Feb 2019 18:58:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 3BD8662445 for ; Tue, 12 Feb 2019 18:58:01 +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 8AA46E278B for ; Tue, 12 Feb 2019 18:58:00 +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 2F97C24487 for ; Tue, 12 Feb 2019 18:58:00 +0000 (UTC) Date: Tue, 12 Feb 2019 18:58:00 +0000 (UTC) From: "Thomas D'Silva (JIRA)" To: issues@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PHOENIX-5132) View indexes with different owners but of the same base table can be assigned same ViewIndexId MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/PHOENIX-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766329#comment-16766329 ] Thomas D'Silva commented on PHOENIX-5132: ----------------------------------------- [~gjacoby] Actually thinking about this some more if the row key is viewIndexId, tenantId then one tenant would not be able to see data from another tenant since we construct the startRow and stopRow of the scan to lead with the viewIndexId and tenantId. In the test were you able to view data from some other tenant using a tenant specific connection? > View indexes with different owners but of the same base table can be assigned same ViewIndexId > ---------------------------------------------------------------------------------------------- > > Key: PHOENIX-5132 > URL: https://issues.apache.org/jira/browse/PHOENIX-5132 > Project: Phoenix > Issue Type: Bug > Affects Versions: 5.0.0, 4.14.1 > Reporter: Geoffrey Jacoby > Assignee: Geoffrey Jacoby > Priority: Critical > Attachments: PHOENIX-5132-4.x-HBase-1.4.patch, PHOENIX-5132-repro.patch > > > All indexes on views for a particular base table are stored in the same physical HBase table. Phoenix distinguishes them by prepending each row key with an encoded short or long integer called a ViewIndexId. > The ViewIndexId is generated by using a sequence to guarantee that each view index id is unique. Unfortunately, the sequence used follows a convention of [SaltByte, Tenant, Schema, BaseTable] for its key, which means that there's a separate sequence for each tenant that owns an index in the view index table. (See MetaDataUtil.getViewIndexSequenceKey) Since all the sequences start at the same value, collisions are not only possible but likely. > I've written a test that confirms the ViewIndexId collision. This means it's very likely that query results using one view index could mistakenly include rows from another index, but I haven't confirmed this. > All view indexes for a base table, regardless of whether globally or tenant-owned, should use the same sequence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)