[
https://issues.apache.org/jira/browse/PHOENIX-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva closed PHOENIX-5018.
-----------------------------------
Bulk closing jiras for the 4.14.2 relase.
> Index mutations created by UPSERT SELECT will have wrong timestamps
> -------------------------------------------------------------------
>
> Key: PHOENIX-5018
> URL: https://issues.apache.org/jira/browse/PHOENIX-5018
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.14.0, 5.0.0
> Reporter: Geoffrey Jacoby
> Assignee: Kadir OZDEMIR
> Priority: Major
> Fix For: 4.15.0, 5.1.0, 4.14.2, 5.0.1
>
> Attachments: PHOENIX-5018.4.x-HBase-1.3.001.patch,
> PHOENIX-5018.4.x-HBase-1.3.002.patch, PHOENIX-5018.4.x-HBase-1.4.001.patch,
> PHOENIX-5018.4.x-HBase-1.4.002.patch, PHOENIX-5018.master.001.patch,
> PHOENIX-5018.master.002.patch, PHOENIX-5018.master.003.patch,
> PHOENIX-5018.master.004.patch
>
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> When doing a full rebuild (or initial async build) of a local or global index
> using IndexTool and PhoenixIndexImportDirectMapper, or doing a synchronous
> initial build of a global index using the index create DDL, we generate the
> index mutations by using an UPSERT SELECT query from the base table to the
> index.
> The timestamps of the mutations use the default HBase behavior, which is to
> take the current wall clock. However, the timestamp of an index KeyValue
> should use the timestamp of the initial KeyValue in the base table.
> Having base table and index timestamps out of sync can cause all sorts of
> weird side effects, such as if the base table has data with an expired TTL
> that isn't expired in the index yet. Also inserting old mutations with new
> timestamps may overwrite the data that has been newly overwritten by the
> regular data path during index build, which would lead to data loss and
> inconsistency issues.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
