Hi, Thirunarayanan! On Jan 16, Thirunarayanan Balathandayuthapani wrote:
revision-id: d08031dfae2 (mariadb-10.0.37-45-gd08031dfae2) parent(s): 12f362c3338 author: Thirunarayanan Balathandayuthapani <thiru@mariadb.com> committer: Thirunarayanan Balathandayuthapani <thiru@mariadb.com> timestamp: 2019-01-16 15:46:28 +0530 message:
MDEV-17376 Server fails to set ADD_PK_INDEX, DROP_PK_INDEX if unique index nominated as PK
Problem: ======== Server fails to notify the engine by not setting the ADD_PK_INDEX and DROP_PK_INDEX When there is a i) Change in candidate for primary key. ii) New candidate for primary key.
Fix: ==== Server sets the ADD_PK_INDEX and DROP_PK_INDEX while doing alter for the above problematic case.
Sorry, that's way too complex. I mean the original code with candidate_key_count, is_candidate_key, and all that. And you're making it more complex. If a unique key is promoted to a primary key, this unique key is always be the first key in the table. So what you need to check is * if the old table didn't have a primary key and the new table has it, then a primary key was added. As easy as if (table->s->primary_key >= MAX_KEY && altered_table->s->primary_key != MAX_KEY) * The opposite case, a primary key was removed * if both tables had a primary key, but the key number 0 in the new table was not key number 0 in the old table - a primary key was changed: if (key_info->usable_key_parts) ... And that should cover all possible cases, as far as I can see. May need some tweaking for key_info->usable_key_parts of newly added indexes, I'm not quite sure what number they get. Regards, Sergei Chief Architect MariaDB and security@mariadb.org