Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
N/A
-
None
Description
The error shown when MAX_EXECUTION_TIME is exceeded:
ERROR 1969 (70100): Query execution was interrupted (max_statement_time exceeded)
|
Is incorrect and can confuse users, as it refers to max_statement_time, another variable which is defined in seconds
(rather than milliseconds like with MAX_EXECUTION_TIME) and employed, for example, in queries like:
SET STATEMENT max_statement_time=1 FOR SELECT SLEEP(1.5); |
Which differ from queries using MAX_EXECUTION_TIME hints.
An improved message would be:
ERROR 1969 (70100): Query execution was interrupted (MAX_EXECUTION_TIME exceeded)
|
Also note the statement vs execution time word difference.
Attachments
Issue Links
- is caused by
-
MDEV-34860 Implement MAX_EXECUTION_TIME hint
-
- Stalled
-
Activity
Perhaps we can have one error code/error but with a variable insert?
ERROR 1969 (70100): Query execution was interrupted (%s exceeded)
|
Where %s is max_statement_time or MAX_EXECUTION_TIME.
This will allow users to tell the true source of the issue - i.e. one feature or the other.
While updating this, perhaps we can also take it one step further and do something like (example):
ERROR 1969 (70100): Query execution was interrupted (query hint MAX_EXECUTION_TIME of 10ms exceeded)
|
ERROR 1969 (70100): Query execution was interrupted (query max_statement_time of 1s exceeded)
|
@Roel, during today's call we discussed adjusting of the error message as below:
ERROR 1969 (70100): Query execution was interrupted (max statement execution time exceeded)
|
So we'd have both `statement` and `execution` keywords in the same message which should cover both use cases.
Everyone seemed to be satisfied with such unification approach, how about you?
Oh, nice combo. I assume it was too complex to use a "%s" variable as is done for other errors (ref ./sql-common/errmsg.c etc)?
Please do what you see as best.
I believe we should better come up with a more common message for both cases, because having two error codes for basically the same scenario doesn't seem reasonable.