[
https://issues.apache.org/jira/browse/PHOENIX-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006943#comment-16006943
]
James Taylor commented on PHOENIX-3811:
---------------------------------------
Upserts aren't idempotent on mutable tables, [~mvanwely]. They need to be
processed in increasing timestamp order or you'll get different results. Simple
example:
* Batch #1 updates A.col1 to 10 at timestamp 1
* Batch #2 updates A.col1 to 20 at timestamp 2
The value of A.col1 should be 20, but it will be 10 if you process Batch #1
after Batch #2.
Using REPLAY_AT and processing in increasing timestamp order is required, not
optional (unless your tables are immutable). Your indexes will not be correct
otherwise.
> Do not disable index on write failure by default
> ------------------------------------------------
>
> Key: PHOENIX-3811
> URL: https://issues.apache.org/jira/browse/PHOENIX-3811
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: James Taylor
> Fix For: 4.11.0
>
> Attachments: PHOENIX-3811_v1.patch, PHOENIX-3811_v2.patch,
> PHOENIX-3811_v3.patch, PHOENIX-3811-wip1.patch, PHOENIX-3811-wip2.patch,
> PHOENIX-3811-wip3.patch, PHOENIX-3811-wip4.patch, PHOENIX-3811-wip5.patch,
> PHOENIX-3811-wip7.patch
>
>
> We should provide a way to configure the system so that the server takes no
> specific action when an index write fails. Since we always throw the write
> failure back to the client, the client can often deal with failures more
> easily than the server since they have the batch of mutations in memory.
> Often times, allowing access to an index that may be one batch behind the
> data table is better than disabling it given the negative performance that
> will occur while the index cannot be written to.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
