maria-developers team mailing list archive
Mailing list archive
Re: d08031dfae2: MDEV-17376 Server fails to set ADD_PK_INDEX, DROP_PK_INDEX if unique index nominated as PK
On Jan 16, Thirunarayanan Balathandayuthapani wrote:
> revision-id: d08031dfae2 (mariadb-10.0.37-45-gd08031dfae2)
> parent(s): 12f362c3338
> author: Thirunarayanan Balathandayuthapani <thiru@xxxxxxxxxxx>
> committer: Thirunarayanan Balathandayuthapani <thiru@xxxxxxxxxxx>
> timestamp: 2019-01-16 15:46:28 +0530
> MDEV-17376 Server fails to set ADD_PK_INDEX, DROP_PK_INDEX if unique index nominated as PK
> 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.
> 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:
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.
Chief Architect MariaDB