[
https://issues.apache.org/jira/browse/PHOENIX-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418185#comment-15418185
]
James Taylor commented on PHOENIX-3176:
---------------------------------------
Looks like the RENEW_LEASE feature is impacting this. If that feature is
disabled, an infinite loop occurs as it did before when running
UpsertSelectAutoCommitIT#testUpsertSelectDoesntSeeUpsertedData. This statement
won't actually run on the server because of the usage of the sequence. I think
it's working now because we have a single scan running instead of the separate
scans per chunk as before. It'd likely still be a problem is a split occurs
while the scan is running, though. It might not cause an infinite loop, but if
the select starts seeing the rows from the upsert, the results will be wrong.
How about adapting that test to force a split while it's running,
[~an...@apache.org] or [~samarthjain]?
This would be a pretty fundamental change, so we need to be careful with it.
Also, if I change that test to not auto commit, but instead commit after the
upsert statements, it fails. That may just mean the count we're returning for
the UPSERT call is wrong, but that'd be a bug too. I filed PHOENIX-3178 for
that. Do you see anything wrong with that test, [~samarthjain]?
> Rows will be skipped which are having future timestamp in row_timestamp column
> ------------------------------------------------------------------------------
>
> Key: PHOENIX-3176
> URL: https://issues.apache.org/jira/browse/PHOENIX-3176
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.6.0
> Reporter: Ankit Singhal
> Fix For: 4.8.1
>
> Attachments: PHOENIX-3176.patch
>
>
> Rows will be skipped when row_timestamp have future timestamp
> {code}
> : jdbc:phoenix:localhost> CREATE TABLE historian.data (
> . . . . . . . . . . . . .> assetid unsigned_int not null,
> . . . . . . . . . . . . .> metricid unsigned_int not null,
> . . . . . . . . . . . . .> ts timestamp not null,
> . . . . . . . . . . . . .> val double
> . . . . . . . . . . . . .> CONSTRAINT pk PRIMARY KEY (assetid, metricid, ts
> row_timestamp))
> . . . . . . . . . . . . .> IMMUTABLE_ROWS=true;
> No rows affected (1.283 seconds)
> 0: jdbc:phoenix:localhost> upsert into historian.data
> values(1,2,'2015-01-01',1.2);
> 1 row affected (0.047 seconds)
> 0: jdbc:phoenix:localhost> upsert into historian.data
> values(1,2,'2018-01-01',1.2);
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> select * from historian.data;
> +----------+-----------+--------------------------+------+
> | ASSETID | METRICID | TS | VAL |
> +----------+-----------+--------------------------+------+
> | 1 | 2 | 2015-01-01 00:00:00.000 | 1.2 |
> +----------+-----------+--------------------------+------+
> 1 row selected (0.04 seconds)
> 0: jdbc:phoenix:localhost> select count(*) from historian.data;
> +-----------+
> | COUNT(1) |
> +-----------+
> | 1 |
> +-----------+
> 1 row selected (0.013 seconds)
> {code}
> Explain plan, where scan range is capped to compile time.
> {code}
> | CLIENT 1-CHUNK PARALLEL 1-WAY FULL SCAN OVER HISTORIAN.DATA |
> | ROW TIMESTAMP FILTER [0, 1470901929982) |
> | SERVER FILTER BY FIRST KEY ONLY |
> | SERVER AGGREGATE INTO SINGLE ROW |
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
