[
https://issues.apache.org/jira/browse/PHOENIX-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816892#comment-16816892
]
Yonatan Gottesman commented on PHOENIX-5233:
--------------------------------------------
As I understand an upsert operation should always do a checkpoint before
scanning and writing to avoid an infinite loop (of scanning values it just
wrote). So i dont see why we only checkpoint if there are no previous
uncommitted data.
I also dont understand how we dont get into an infinite loop:
Look at UpsertCompiler:
line 224 (_while (rs.next(_)) {) we scan through the table and if we reach the
batch size (line 250) we write data to the table, how come this data isnt read
later by the scan in 224? maybe we had luck and for some reason this data isnt
read so we dont get into an infinite loop, but when a split happens we do start
seeing this data again?
just a thought, im still not sure whats going on...
> 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)
