maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Thirunarayanan!

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
> 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@xxxxxxxxxxx