phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonatan Gottesman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-5233) Read-your-own writes causes incorrect visibility with transactional tables (with Omid).
Date Sun, 14 Apr 2019 05:34:00 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817200#comment-16817200
] 

Yonatan Gottesman commented on PHOENIX-5233:
--------------------------------------------

Cool so this is exactly the problem. The checkpoint in omid was created just for phoenix upsert
operation without taking to account hbase mvcc so there is nothing to fix in omid.

I see checkpointIfNeccessary is always called will this cause checkpointing in other operations
other than upsert? In omid there is a limit to 50 checkpoints per transaction, it can be more
but there has to be a limit because the timestamps jump with this value.

So can this happen for more than upsert and is 50 enough?

> Read-your-own writes causes incorrect visibility with transactional tables (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-tests.txt, 5233-v4.txt, 5233-v5.txt, 5233-v6.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 integer not null,
v1 float, v2 float, v3 integer CONSTRAINT pk PRIMARY KEY (pk1, pk2, pk3)) DISABLE_WAL=true,
TRANSACTIONAL=true;}}
>  # {{upsert into test values(rand()*10000000, rand()*10000000, rand()*10000000, rand(),
rand(), rand()*1000000);}}
>  # {{upsert into test select rand()*10000000, rand()*10000000, rand()*10000000, rand(),
rand(), rand()*1000000 from test;}}
>  # {{select count\(*) from test; – this will cause uncommitted data 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)

Mime
View raw message