Description:
Two bugs found in 4.0.x branch.
First bug causes mysql either to crash or return nothing when doind
select something from table where blob like '%something%';
the column is trivial - just a not-null blob column. However, everything
is
fine on 3.23.54a.
The second bug causes MySQL to fail start upon upgrade from 4.0.7 if
InnoDB
is not used yet not disabled by skip-innodb.
Both testcases are uploaded to the secret url named
ensita-egor-bug?.tar.bz2
Both archives has "case.txt" file in it, describing the problem
and
how-to-repeat.
OS is RH Linux 7.3, MySQL is the official binary from RPM.
How to repeat:
Two bugs found in 4.0.x branch.
First bug causes mysql either to crash or return nothing when doind
select something from table where blob like '%something%';
the column is trivial - just a not-null blob column. However, everything
is
fine on 3.23.54a.
The second bug causes MySQL to fail start upon upgrade from 4.0.7 if
InnoDB
is not used yet not disabled by skip-innodb.
Both testcases are uploaded to the secret url named
ensita-egor-bug?.tar.bz2
Both archives has "case.txt" file in it, describing the problem
and
how-to-repeat.
OS is RH Linux 7.3, MySQL is the official binary from RPM.
Suggested fix:
> What happened below was probably that you had old ib_logfiles left in
the
> datadir. Below InnoDB complains about that and instructs you to
delete
those
> obsolete ib_logfiles. When you the next time start mysqld, InnoDB
assumes
> that it should do a recovery using those wrong ib_logfiles. Of
course,
that
> does not work, and a crash follows.
>
> I can think of an improvement: InnoDB could always after a successful
> startup stamp ibdatas and Ib_logfiles so that it could warn if
someone
tries
> to use incompatible files together.
>
> Regards,
>
> Heikki
