From issues-return-5874-archive-asf-public=cust-asf.ponee.io@phoenix.apache.org Wed Apr 10 19:07:02 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 [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 9CC5F180763 for ; Wed, 10 Apr 2019 21:07:02 +0200 (CEST) Received: (qmail 29063 invoked by uid 500); 10 Apr 2019 19:07:02 -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 29054 invoked by uid 99); 10 Apr 2019 19:07:01 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Apr 2019 19:07:01 +0000 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 D0FE2E2A76 for ; Wed, 10 Apr 2019 19:07: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 32DF82459F for ; Wed, 10 Apr 2019 19:07:00 +0000 (UTC) Date: Wed, 10 Apr 2019 19:07:00 +0000 (UTC) From: "Lars Hofhansl (JIRA)" To: issues@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (PHOENIX-5233) Read-your-own writes causes incorrect visibility with transactional tables (with Omid). MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/PHOENIX-5233?page=3Dcom.atlassi= an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D16= 814797#comment-16814797 ]=20 Lars Hofhansl edited comment on PHOENIX-5233 at 4/10/19 7:06 PM: ----------------------------------------------------------------- I see exactly the same. Yes, it sees more data (also see 1924). Because HBa= se split, scanners are restarted, and hence the same rows might come in twi= ce, and the transaction manager still has to make sure that we see a snapsh= ot of the table even in the local transaction. I think that's why the check= point is always needed. (Without transactions we solve it by mocking with the timestamps, but neith= er works nor would it be correct in the transactional case. Check for "same= Table" in UpsertCompiler to see how it works.) I should add that in the second case above (where I see partial data via an= other connection) I actually see fewer rows... I'm trying to create a test = for that. was (Author: lhofhansl): I see exactly the same. Yes, it sees more data (also see 1924). Because HBa= se split, scanners are restarted, and hence the same rows might come in twi= ce, and the transaction manager still has to make sure that we see a snapsh= ot of the table even in the local transaction. I think that's why the check= point is always needed. (Without transactions we solve it by mocking with the timestamps, but neith= er works nor would it be correct in the transactional case. Check for "same= Table" in UpsertCompiler to see how it works.) I should add that in the second case above (where I see partial data via an= other connection I actually see fewer rows... I'm trying to create a test f= or that.) > Read-your-own writes causes incorrect visibility with transactional table= s (with Omid). > -------------------------------------------------------------------------= -------------- > > Key: PHOENIX-5233 > URL: https://issues.apache.org/jira/browse/PHOENIX-5233 > Project: Phoenix > Issue Type: Bug > Affects Versions: 4.14.1 > Reporter: Lars Hofhansl > Assignee: Yonatan Gottesman > Priority: Major > Attachments: 5233-test-only.txt, 5233-v4.txt, 5233-v5.txt, 5233-v= 6.txt > > > (copied from my last comment on PHOENIX-5090) > Steps to reproduce (with Omid): > # {{!autocommit off}} > # {{create table test (pk1 integer not null, pk2 integer not null, pk3 i= nteger not null, v1 float, v2 float, v3 integer CONSTRAINT pk PRIMARY KEY (= pk1, pk2, pk3)) DISABLE_WAL=3Dtrue, TRANSACTIONAL=3Dtrue;}} > # {{upsert into test values(rand()*10000000, rand()*10000000, rand()*100= 00000, rand(), rand(), rand()*1000000);}} > # {{upsert into test select rand()*10000000, rand()*10000000, rand()*100= 00000, rand(), rand(), rand()*1000000 from test;}} > # {{select count\(*) from test; =E2=80=93 this will cause uncommitted da= ta to sent to the server.}} > # Goto #4 a few time (until you inserted 131072 rows) > # {{!commit}} > In a separate sqlline session just repeat after the commit was issued in = the other session. > * {{select count\(*) from test;}} > You'll see that number will change until it finally settles. -- This message was sent by Atlassian JIRA (v7.6.3#76005)