Hi, Oleksandr!
On Aug 29, Oleksandr Byelkin wrote:
> >> === modified file 'sql/sql_update.cc'
> >> --- a/sql/sql_update.cc 2012-04-26 17:21:37 +0000
> >> +++ b/sql/sql_update.cc 2012-08-27 14:29:26 +0000
> >> @@ -872,7 +872,7 @@ int mysql_update(THD *thd,
> >> id= thd->arg_of_last_insert_id_function ?
> >> thd->first_successful_insert_id_in_prev_stmt : 0;
> >>
> >> - if (error < 0)
> >> + if (error < 0 && (!thd->is_error()))
> >> {
> >> char buff[MYSQL_ERRMSG_SIZE];
> >> my_snprintf(buff, sizeof(buff), ER(ER_UPDATE_INFO), (ulong) found,
> >> (ulong) updated,
> > Nope, this is not good.
> > The bug happens because the error from remove_eq_conds() is ignored.
> > You need to catch and process this error as soon as possible.
> > While in your patch you let the update work all the way till the end.
> >
> When "update works all the way" it catched inside update loops, but was
> that if update never make any update it ignores errors.
>
> So actually it should be my fix or both fixes, because errors
> (especially such unexpected as "out of resources" could happened almost
> anywhere, so issuing OK to the client without checking error state is a
> mistake.
I know. Before sending a review I actually tried to get a crash by
generating an error in different places of the UPDATE.
E.g. in the loop:
INSERT t1 VALUES (1,2); UPDATE ....
or in fill_record():
UPDATE t1 SET a=COLUMN_CREATE(...);
or with double my_error():
... WHERE COLUMN_CREATE(...) OR COLUMN_CREATE(...);
all these cases were correctly taken care of, no crash, no ok packet.
So, I think, it's enough to fix only that early failure that you have found.
Regards,
Sergei
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
