maria-developers team mailing list archive

[Marko Mäkelä <marko.makela@xxxxxxxxxxx>]

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

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