phoenix-issues mailing list archives

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

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

James Taylor commented on PHOENIX-5233:
---------------------------------------

The Visibility filter in Omid should filter out in-flight transactions from other clients
until those in-flight transactions are committed, so something is wrong here. The checkpoint
is only needed for the corner case of reading from the same table you're writing to. The checkpoint
prevents the client from seeing its own writes within the same statement. HBase does this
as well, but not if a split occurs while the statement is running.

Perhaps the checkpointing is causing the problem? You might try another test that writes to
a different table than it's reading from. Or just make the checkpointing a noop and see if
it works as expected.

> 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
>
> (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