Hi Kostja...
On Thu, Sep 25, 2008 at 07:25:26PM +0400, Konstantin Osipov wrote:
> * Sergey Vojtovich <svoj@stripped> [08/09/25 18:58]:
> > 2832 Sergey Vojtovich 2008-09-25
> > BUG#34892 - Transaction handling in select_create::abort let's Falcon
> fail
>
> trans_rollback_statement() should be done on top level, when we
> send the error message.
Completely agree. But this way the code of CREATE ... SELECT would need
some refactoring.
The problem is that CREATE ... SELECT calls mysql_unlock_tables() way
to early (= means we release storage engine internal savepoint earlier
than we should do it). Later trans_rollback() gets called, which does
nothing in general (because the savepoint was released earlier in
mysql_unlock_tables).
Though I believe the engine behaves correctly, I'd say the API is not
complete enough with this regard.
> Is there any reason why this doesn't work?
Yes, there definitely is. See above.
> Perhaps worth adding an explanation in a comment then.
There are a lot of comments aroung select_create::abort() and
select_insert::abort() explaining why do we rollback here.
Regards,
Sergey
> >
> > === modified file 'sql/sql_insert.cc'
> > --- a/sql/sql_insert.cc 2008-09-16 17:58:49 +0000
> > +++ b/sql/sql_insert.cc 2008-09-25 14:39:39 +0000
> > @@ -3310,6 +3310,7 @@ void select_insert::abort() {
> > thd->transaction.stmt.modified_non_trans_table);
> > table->file->ha_release_auto_increment();
> > }
> > + trans_rollback_stmt(thd);
> >
> > DBUG_VOID_RETURN;
> > }
> --
--
Sergey Vojtovich <svoj@stripped>
MySQL AB, Software Engineer
Izhevsk, Russia, www.mysql.com
