You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Sahil Takiar (Jira)" <ji...@apache.org> on 2020/07/09 18:10:00 UTC

[jira] [Resolved] (IMPALA-9734) ACID-query retry integration

     [ https://issues.apache.org/jira/browse/IMPALA-9734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sahil Takiar resolved IMPALA-9734.
----------------------------------
    Resolution: Not A Problem

After talking with several folks offline. This does not seem to be an issue. Impala currently does not open a transaction for read-only queries (although Hive does, and perhaps Impala will at some point in the future). Transactions are only opened for write-only queries. Transparent query retries currently don't support write queries (and there are no current plans to implement this in the near-term).

The only ACID consideration is that the snapshot view of the data from the original query should be the same view of the data in the retried query. e.g. the set of files and version of the tables scanned in the original query should be the same for the retried query. The current transparent query logic already handles this because the TExecRequest is simply copied from the original query to the retried query. The planning phase will be skipped, so the set of files will to be scanned will be the same.

> ACID-query retry integration
> ----------------------------
>
>                 Key: IMPALA-9734
>                 URL: https://issues.apache.org/jira/browse/IMPALA-9734
>             Project: IMPALA
>          Issue Type: Sub-task
>            Reporter: Sahil Takiar
>            Priority: Major
>
> We need to consider how query retries interact with ACID transactions. As of IMPALA-9199, Impala will create new ClientRequestStates for each query retry and will cache the TExecRequest between ClientRequestStates. This might not be safe for ACID transactions. If the first query attempt fails, then the transaction will fail and a new one will be required. However, the query retry will use the transaction id / info from the original query attempt.
> I think the semantics are not entirely clear here, and we don't have any tests for this. So the goal of this JIRA is to (1) identify if there are any issues with the current approach, (2) fix any issues with transactions during query retries, and (3) add some query retry tests that enable transactions.
> We might want to consider whether a query and it's retry should be in the same, or different transactions. Keeping them in the same transaction should allow us cache the TExecRequest. If they are in separate transactions, then Impala might need to create a new TExecRequest for each retry.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org