Query Error when checking user privileges

Question

Query Error when checking user privileges

OllieJones opened this issue 2 years ago · comments

On a NearlyFreeSpeech.net - hosted site (FreeBSD) the Query Monitor shows this query-error message.

SELECT COUNT(*) numFROM mysql.userWHERE CONCAT_WS('@', User, Host) = USER()AND Process_priv <> 'Y'/**imfs-query-tag*397099888*/ 
+ImfsDb->get_results()
Plugin: index-wp-mysql-for-speed
Illegal mix of collations (utf8mb4_general_ci,COERCIBLE) and (utf8mb4_unicode_ci,COERCIBLE) for operation '<>'  
1267

Everything works otherwise.

Looks like a clash of cultures.

(This bug was discovered by this repo's owner)

Rick James · Answer 1 · Thu Feb 24 2022 08:56:18 GMT+0800 (China Standard Time)

It seems strange to be looking inside `mysql.user`. Is that being done by the app? `SHOW VARIABLES LIKE "coll%";` -- possibly the connection is part of the problem.On 8.0, I see `Process_priv` enum('N','Y') CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT 'N', Meanwhile, I would not trust `CONCAT_WS()` to deliver the correct charaset or collation. Rick Jamesemail: ***@***.*** On Wednesday, February 23, 2022, 04:43:40 PM PST, Oliver Jones ***@***.***> wrote: On a NearlyFreeSpeech.net - hosted site (FreeBSD) the Query Monitor shows this query-error message. SELECT COUNT(*) numFROM mysql.userWHERE CONCAT_WS('@', User, Host) = USER()AND Process_priv <> 'Y'/**imfs-query-tag*397099888*/ +ImfsDb->get_results() Plugin: index-wp-mysql-for-speed Illegal mix of collations (utf8mb4_general_ci,COERCIBLE) and (utf8mb4_unicode_ci,COERCIBLE) for operation '<>' 1267 Everything works otherwise. Looks like a clash of cultures. (This bug was discovered by this repo's owner) — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Oliver Jones · Answer 2 · Sat Feb 26 2022 02:18:31 GMT+0800 (China Standard Time)

The query is in the plugin. Its purpose is to determine whether the active database user has the PROCESS priv, before attempting to read the information_schema.INNODB_METRICS table. Reading the mysql.users table is the canonical way of doing that. I guess this query failed because of a mismatch between the enum's collation and the connection collation. On that particular configuration. Right now it's cosmetic only; it prevents the uploaded metadata from including the INNODB_METRICS table. It might, in future, figure more into choosing indexes.

Rick James · Answer 3 · Sat Feb 26 2022 23:52:46 GMT+0800 (China Standard Time)

Might it be better to simply try to read INNODB_METRICS and catch the failure? Rick Jamesemail: ***@***.*** On Friday, February 25, 2022, 10:18:43 AM PST, Oliver Jones ***@***.***> wrote: The query is in the plugin. Its purpose is to determine whether the active database user has the PROCESS priv, before attempting to read the information_schema.INNODB_METRICS table. Reading the mysql.users table is the canonical way of doing that. I guess this query failed because of a mismatch between the enum's collation and the connection collation. On that particular configuration. Right now it's cosmetic only; it prevents the uploaded metadata from including the INNODB_METRICS table. It might, in future, figure more into choosing indexes. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: ***@***.***>

Oliver Jones · Answer 4 · Thu Mar 03 2022 17:54:47 GMT+0800 (China Standard Time)

The problem is this: WordPress logs caught database exceptions. There've been some complaints from users about that. So I'm trying to prevent those database exceptions. At any rate, fixed.