[
https://issues.apache.org/jira/browse/KUDU-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15686013#comment-15686013
]
David Alves commented on KUDU-1704:
-----------------------------------
IMO it doesn't make sense to have the use specify a scan timestamp (otherwise
it's just a snapshot scan).
In fact this is much like a snapshot scan with the difference that the server
can choose an arbitrarily old timestamp as long as it bigger than the
propagated timestamp from the scan request. If the scan request does not
contain a propagated timestamp then the server should be free to choose the
last "clean" one.
To clarify this a little bit: Mvcc has the concept of a "clean" timestamp,
which is a timestamp in the past before which all transactions are committed
and therefore repeatable. READ_AT_SNAPSHOT scans without a timestamp have to
choose "now" and then wait for it to become "clean". The point of this mode is
that for RYW (not linearizability) we don't need to read at "now" we can read
arbitrarily in the past as long as the timestamp we choose for the read is
higher than the timestamp of the last write/read we know of (the propagated
timestamp).
Moreover each server should be free to choose a timestamp such as this, as long
as it respects the aforementioned condition, which is why we shouldn't reuse
timestamps across servers in this mode and shouldn't return the chosen snapshot
timestamp back to the client.
> Add a new read mode to perform bounded staleness snapshot reads
> ---------------------------------------------------------------
>
> Key: KUDU-1704
> URL: https://issues.apache.org/jira/browse/KUDU-1704
> Project: Kudu
> Issue Type: Sub-task
> Affects Versions: 1.1.0
> Reporter: David Alves
> Assignee: Alexey Serbin
>
> It would be useful to be able to perform snapshot reads at a timestamp that
> is higher than a client provided timestamp, thus improving recency, but lower
> that the server's oldest inflight transaction, thus minimizing the scan's
> chance to block.
> Such a mode would not guarantee linearizability, but would still allow for
> client-local read-your-writes, which seems to be one of the properties users
> care about the most.
> This should likely be the new default read mode for scanners.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
