Details
-
Improvement
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
1.0.0
-
None
Description
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”
Attachments
Attachments
Issue Links
- depends upon
-
HIVE-12832 RDBMS schema changes for HIVE-11388
-
- Closed
-
- relates to
-
HIVE-11793 SHOW LOCKS with DbTxnManager ignores filter options
-
- Closed
-
1.
|
Thrift and RDBMS changes for HIVE-10249 |
|
Resolved | Alan Gates |