[MDEV-18108] Unknown error 188 Created: 2018-12-31  Updated: 2021-11-03

Status: Confirmed
Project: MariaDB Server
Component/s: Server, Storage Engine - Aria, Storage Engine - InnoDB, Storage Engine - MyISAM
Affects Version/s: 5.5, 10.0, 10.1, 10.2, 10.3
Fix Version/s: 10.4

Type: Bug Priority: Minor
Reporter: Casper Langemeijer Assignee: Sergei Golubchik
Resolution: Unresolved Votes: 1
Labels: None


 Description   

I have a query that very sporadically returns with 'Unknown error 188'.

This could well be caused by a time limit set with SET max_statement_time statement, but I'm not sure.

In the mariadb source code I found these define statements:
#define HA_ERR_ABORTED_BY_USER 188
and
#define HA_ERR_QUERY_INTERRUPTED HA_ERR_ABORTED_BY_USER

The documentation for max_statement_time does not state any error codes that could be interpreted as a query that is aborted due to a time limit. So far I've found that
error 1028 - Sort aborted and 1969 - Query execution was interrupted (max_statement_time exceeded) can happen.

Should I add 188 to this list in my application? Or is this a bug and should error 1969 be returned instead of 188?

 Comments   
Comment by Elena Stepanova [ 2018-12-31 ]

Is it always the same query? Please provide it. You can obfuscate the names of involved objects if necessary.

Comment by Elena Stepanova [ 2018-12-31 ]

Thank you.
Indeed, full-text search is one of not-so-many places where the raw HA_ERR_ABORTED_BY_USER or HA_ERR_QUERY_INTERRUPTED are issued. There is even a test in 10.3 which expects it.

In general, the code appears to be used by MyISAM, Aria and InnoDB. The latter converts its DB_INTERRUPTED into HA_ERR_ABORTED_BY_USER.

It doesn't look like an obvious bug to me, maybe it could be classified as an unfortunate legacy. I wonder if it can be improved in future – for example, TokuDB seems to be able to convert TOKUDB_INTERRUPTED into a more civilized ER_QUERY_INTERRUPTED, possibly at least InnoDB could do the same. MyISAM and Aria have more references to ERR_ABORTED_BY_USER, and strangely there are some in sql_select.cc.
I'll assign it to serg and ping marko to decide if a change is needed here; but in any case, it's unlikely to happen in any GA.

I think it's fine to add 188 to the list of codes. Also, it won't be very surprising if you encounter 1317 (ER_QUERY_INTERRUPTED). In many ways max_statement_time behaves similar to KILL QUERY, I'm not sure it is always possible to determine the exact reason of the interruption, so ER_QUERY_INTERRUPTED might occur instead of ER_STATEMENT_TIMEOUT.

Comment by Manuel [ 2019-06-30 ]

Same problem with MariaDB 10.4.6 and this query:

SET STATEMENT max_statement_time=10 FOR (SELECT outfit.id, outfit.title, outfit.description, outfit.category, outfit.idcustomer, outfit.o_username as authorname FROM outfit WHERE outfit.countries_id = 1 AND MATCH (outfit.title,outfit.description) AGAINST ('matrimonio damigella sposa testimone' IN BOOLEAN MODE) and category = 'women' and online = true and datepublishfrom <= '2019-06-30 08:30:00' ORDER BY id desc LIMIT 35,5)

For now it happened to me once upon thousands of queries executed.

Comment by Jan Willamowius [ 2021-11-03 ]

The issue still exists in 10.6.4.

InnoDB fulltext queries that hit the time limit return error 1969 (and they actually abort when the time limit is reached), while fulltext searches on Aria tables return error 188 when the time limit is reached, but they don't abort, but run almost the full time as if no time limit were set but return no result set. (see MDEV-26311)

Generated at Thu Feb 08 08:41:33 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.