On Thu, 6 Jul 2023 at 01:22, Sergei Golubchik <serg@mariadb.org> wrote:
LEX_CSTRING defines a string by a pointer and a length. You shouldn't use functions that stop at first '\0'.
In some contexts (for table names, for example) it might be ok, but here you create a generic LEX_CSTRING concatenation, let's not implicitly assume that there are not zero bytes inside.
Ouch! Right, there are more encodings than I can encounter. In fact, i don't even know if 0 can be met in any sort of utf.
@@ -9869,26 +9869,21 @@ bool online_alter_check_autoinc(const THD *thd, const Alter_info *alter_info,
*/ for (uint k= 0; k < table->s->keys; k++) { - const KEY &key= table->s->key_info[k]; + const KEY &key= table->key_info[k];
This is generally incorrect. User specified keys are in table->s->key_info[] Keys in table->key_info[] can be modified to match what indexes are actually created, in particular, for long uniques table->key_info[] differs from table->s->key_info[]
Maybe, but hopefully, long unique is not HA_NOSAME. I need table->key[i].key_part[j].field to compare with copy_field.field.
can you compare indices instead?
I can, but why do you suppose table->s->key_info is the correct one? Rows_log_event::find_key enumerates table->key-info to find a unique key.
It only checks m_table->s->keys_in_use.is_set(i). Though it seems unrelated, I suppose I could have to check it as well, but I couldn't find what drives its values apart from ALTER TABLE DISABLE KEYS, which skips unique keys. What do you think?
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
-- Yours truly, Nikita Malyavin