Hi Sergei, On January 16, 2019, Sergei Golubchik wrote:
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.
Yes, it is complex, but this patch already went through some rounds of my review, and this was the best we could come up without a major refactoring.
If a unique key is promoted to a primary key, this unique key is always be the first key in the table.
According to some comments in InnoDB, this might not have been the case in tables that were created in MySQL 3.23. But that would not be the first time when a comment in InnoDB source code has been inaccurate or incorrect. As far as we can tell, table->s->primary_key is always either 0 or MAX_KEY. Do you know if this has ever been different earlier?
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)
It would be as easy as that if altered_table had already been constructed. But it seems to me that it would be constructed based on the output of this function. Perhaps we should set the flags somewhat later based on comparing table and altered_table? Best regards, Marko