Non-ASCII rendering of apostrophe in LOCK TABLES FOR BACKUP error message

It's an RQG bug. Detecting "database corruption" by unicode characters in an error message is a bit naive. Unicode characters are valid in error messages.

It is an RQG bug indeed. But is there a good reason for having a non-ASCII apostrophe there? It diffs poorly for one thing, as fixing the bug has shown.

I don't see any problems with diff. In fact, the character is not even unicode, but is extended ASCII.

In MTR result files it diffs showing the extended ASCII code:

-ERROR HY000: Can<92>t execute the query because you have a conflicting backup lock
+ERROR HY000: Can't execute the query because you have a conflicting backup lock

in the error message file it diffs showing the three UTF-8 bytes:

- eng "Can<E2><80><99>t execute the query because you have a conflicting backup lock"
+ eng "Can't execute the query because you have a conflicting backup lock"

That's correct, because in errmsg-utf8.txt it is stored in, well, UTF-8.

MTR executes tests with the default character set (latin1), so the unicode character is converted to it's extended ASCII equivalent, which is also present in latin1.

[share]$ cat errmsg-utf8.txt | grep "execute the query because you"
        eng "Can't execute the query because you have a conflicting read lock"
        eng "Can't execute the query because you have a conflicting backup lock"

[share]$ cat errmsg-utf8.txt | grep "execute the query because you" | hexdump -C
00000000 20 20 20 20 20 20 20 20 65 6e 67 20 22 43 61 6e | eng "Can|
00000010 27 74 20 65 78 65 63 75 74 65 20 74 68 65 20 71 |'t execute the q| <--- 1 byte, fine
00000020 75 65 72 79 20 62 65 63 61 75 73 65 20 79 6f 75 |uery because you|
00000030 20 68 61 76 65 20 61 20 63 6f 6e 66 6c 69 63 74 | have a conflict|
00000040 69 6e 67 20 72 65 61 64 20 6c 6f 63 6b 22 0a 09 |ing read lock"..|
00000050 65 6e 67 20 22 43 61 6e e2 80 99 74 20 65 78 65 |eng "Can...t exe| <--- 3 bytes
00000060 63 75 74 65 20 74 68 65 20 71 75 65 72 79 20 62 |cute the query b|
00000070 65 63 61 75 73 65 20 79 6f 75 20 68 61 76 65 20 |ecause you have |
00000080 61 20 63 6f 6e 66 6c 69 63 74 69 6e 67 20 62 61 |a conflicting ba|
00000090 63 6b 75 70 20 6c 6f 63 6b 22 0a |ckup lock".|
0000009b

Every other ' in the file is correct.

[roel@localhost share]$ cat errmsg-utf8.txt | grep -i "Can.t" | hexdump -C | grep -i "Can.t" | wc -l
58
[roel@localhost share]$ cat errmsg-utf8.txt | grep -i "Can.t" | hexdump -C | grep -i "Can...t" | wc -l
1

Without this fix QA will remove LOCK TABLES FOR BACKUP testing from RQG as we are not at liberty to change RQG in this area (nor would we - see MS Bugs 42685 and 47412 which clearly show this not to be a naive idea)

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-3177