[
https://issues.apache.org/jira/browse/HIVE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Koifman updated HIVE-10249:
----------------------------------
Resolution: Fixed
Fix Version/s: 2.1.0
1.3.0
Status: Resolved (was: Patch Available)
master:
https://github.com/apache/hive/commit/4e9f95a1bad89ac4ea0cefc65eeba7a1e56a948d
branch-1:
https://github.com/apache/hive/commit/b6f6c4acba3b863851d197a7e6e2e9f4b851da70
> ACID: show locks should show who the lock is waiting for
> --------------------------------------------------------
>
> Key: HIVE-10249
> URL: https://issues.apache.org/jira/browse/HIVE-10249
> Project: Hive
> Issue Type: Improvement
> Components: Transactions
> Affects Versions: 1.0.0
> Reporter: Eugene Koifman
> Assignee: Eugene Koifman
> Priority: Critical
> Fix For: 1.3.0, 2.1.0
>
> Attachments: HIVE-10249.2.patch, HIVE-10249.3.patch, HIVE-10249.patch
>
>
> instead of just showing state WAITING, we should include what the lock is
> waiting for. It will make diagnostics easier.
> It would also be useful to add QueryPlan.getQueryId() so it's easy to see
> which query the lock belongs to.
> # need to store this in HIVE_LOCKS (additional field); this has a perf hit to
> do another update on failed attempt and to clear filed on successful attempt.
> (Actually on success, we update anyway). How exactly would this be
> displayed? Each lock can block but we acquire all parts of external lock at
> once. Since we stop at first one that blocked, we’d only update that one…
> # This needs a matching Thrift change to pass to client: ShowLocksResponse
> # Perhaps we can start updating this info after lock was in W state for some
> time to reduce perf hit.
> # This is mostly useful for “Why is my query stuck”
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
