I'd guess the replication unsafety thing was because the "CREATE TABLE t1 ENGINE=MEMORY AS SELECT REPEAT('a',5) AS a LIMIT 0" being used in the test was being marked as unsafe for replication, despite having a LIMIT 0 making it deterministic. However, fixing that bug within this fix is kind of unexpected (and I would note that the new behavior is not being specifically tested here).

Bar: Could you comment as to why MY_CS_STRNXFRM is not needed for my_charset_utf8mb4_bin? And/or why the other changes to filesort were not necessary here? Trying to understand the differences.

Jeremy, you're right.
"CREATE TABLE t1 AS SELECT REPEAT('a',N) AS a LIMIT 0" has been always used
in tests to create a VARCHAR(N) column using the current value of @@collation_connection.
It worked fine with all tests not using binlog with statement format.

A fix for MDEV-6170 added a new test into include/ctype_filesort.inc,
to cover as many collations as possible (not only utf8_bin).
As a result, the test binlog_stm_ctype_cp932 started to fail with the error
"Unsafe statement written to the binary log using statement...".
The easiest way was to make "SELECT .. LIMIT 0" deterministic,
which was erroneously not. So the patch actually fixes two problems.

The new behaviour IS tested in binlog_stm_ctype_cp932.

By the way, the old behaviour of "LIMIT 0" was not tested,
neither specifically, nor indirectly.

Jeremy,

MY_CS_STRNXFRM is needed for my_charset_utf8mb4_bin,
and it is there in ctype-utf8.c, around 8158:

struct charset_info_st my_charset_utf8mb4_bin=

{

  46,0,0,             /* number       */

  MY_CS_COMPILED|MY_CS_BINSORT|MY_CS_STRNXFRM|MY_CS_UNICODE|

  MY_CS_UNICODE_SUPPLEMENT, /* state  */

MY_CS_STRNXFRM is needed for all collations (including utf8_bin and utf8mb4_bin)
that use something more complex than just a prefix of the original string to create a binary sortable image.

• utf8_bin transforms variable length 1-3 bytes sequences into fixed length 2 byte sequences.
• utf8mb4_bin transforms variable length 1-4 bytes sequences into fixed length 3 byte sequences.

These transformation are done for performance purposes: to reduce the length needed to sort data.

Bar,

Yes, I see that MY_CS_STRNXFRM is present already for utf8mb4, I was looking at a too-old version in my case.

I do however disagree that the new behavior is specifically tested; it's indirectly/incidentally tested as part of the ctype test. It should get a new test, with a decent name, to test specifically that LIMIT 0 causes the warning to not be generated while e.g. LIMIT 1 does not. It doesn't matter what was there before, it matters what you're changing and that we're improving the situation. This should get a new, specific test.