You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Alexey Serbin (JIRA)" <ji...@apache.org> on 2016/11/28 05:15:59 UTC

[jira] [Comment Edited] (KUDU-1679) Propagate timestamps for scans

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

Alexey Serbin edited comment on KUDU-1679 at 11/28/16 5:15 AM:
---------------------------------------------------------------

[~dralves] nope, that part I did only for the C++ client.  Need to do that for Java as well.  Will prepare a patch soon.


was (Author: aserbin):
[~dralves] nope, that's part I did only for the C++ client.  Need to do that for Java as well.

> Propagate timestamps for scans
> ------------------------------
>
>                 Key: KUDU-1679
>                 URL: https://issues.apache.org/jira/browse/KUDU-1679
>             Project: Kudu
>          Issue Type: Sub-task
>          Components: tserver
>    Affects Versions: 1.0.1
>            Reporter: David Alves
>            Assignee: Alexey Serbin
>
> We only propagate timestamps from writes to reads, not between two reads. This leaves the door open to unrepeatable read anomalies:
> If T1, T2 are reads from the same client where T2 starts after the response from T1 is received and neither are assigned timestamps by the client. It might be the case where T2’s observed value actually precedes T1’s value in the row history if T1 and T2 are performed in different servers, as T2 can be assigned a timestamp that is lower than T1.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)