Andrei Elkin wrote:
>> Andrei Elkin wrote:
>>> Mats, hello.
>>>
>>>> Andrei Elkin wrote:
>>>>> Mats,
>>>>>
>>>>> I wonder if this is the most recent commit ...
>>>>> But that's the lattest that I found in commits@.
>>>>>
>>>>>> #At
> bzr+ssh://bk-internal.mysql.com/bzrroot/server/mysql-6.0-falcon/
>>>>>>
>>>>>> 2695 Mats Kindahl 2008-06-09
>>>>>> Bug #37221: SET AUTOCOMMIT=1 does not commit binary log
>>>>>>
>>>>>> When setting AUTOCOMMIT=1 after starting a transaction, the
> binary log
>>>>>> did not commit the outstanding transaction. The reason was
> that the binary
>>>>>> log commit function saw the values of the new settings,
> deciding that there
>>>>>> were nothing to commit.
>>>>>>
>>>>> The problem description left unattended although you agreed on the
> last review mail:
>>>>>
>>>>> > A SET AUTOCOMMIT=1 does not commit a transaction started
> with BEGIN and
>>>>> > therefore there is nothing in binlog, either engine. This
> contradicts
>>>>> > to the current docs.
>>>>> >
>>>>> > B If a Falcon transaction is started with SET AUTOCOMMIT= 0
> committing with
>>>>> > SET AUTOCOMMIT=1 to engine works but nothing in binlog, as
> you are
>>>>> > reporting.
>>>>> >
>>>>> > I think both issues comprise the whole problem.
>>>>>
>>>>> Agree.
>>>> Ehw... the problem description stays the same because this is what it
>>>> was about. The problem A is is not part of this patch, the engine
>>>> committed properly before I applied this patch, it is just problem B,
>>>> i.e. that the call of binlog_commit() sees the new values of the options
>>>> instead of the old values, and therefore make the wrong decision of not
>>>> committing the transaction *to the binary log*.
>>>>
>>> Let's come to consensus.
>>>
>>> Here is the case that has not worked as specified, regardless of the
>>> table type:
>>>
>>> create table t1 (a int) engine= falcon or innodb;
>>> set autocommit=1;
>
>> It should be:
>
> Why it should be so?
12.4.3. Statements That Cause an Implicit Commit
Each of the following statements (and any synonyms for them) implicitly
end a transaction, as if you had done a COMMIT before executing the
statement:
* .... SET AUTOCOMMIT=1 (if the value is not already 1)
>
>> set autocommit=0;
>>
>>> begin;
>>> insert into t1 values (1);
>>> SET AUTOCOMMIT=1;
>>>
>>> The last `SET AUTOCOMMIT=1' does not commit.
>> With the change above, that is true for the code before the patch.
>>
>>> Does it commit in your env?
>> Yes, it commits both the engine and the binary log with the patch. It
>> just commits the engine without the patch.
>
> Mats, excuse me, but I was asking if the sequence of
>
>>> SET AUTOCOMMIT=1;
>>> BEGIN;
>>> insert into t1 values (1);
>>> SET AUTOCOMMIT=1;
>
> commits?
No, it does not commit, as can be seen from the result file of the test
that was part of the patch.
> Not this one
>
> SET AUTOCOMMIT=0;
> BEGIN;
> insert into t1 values (1);
> SET AUTOCOMMIT=1;
>
> Could you please check if it suprisingly works is your env?
It is part of the tests for the patch and is is very clear that it does
not commit a started transaction.
> If it does not then we are dealing with the case A - no commit while
> it is supposed to be.
It does not commit the ongoing transaction.
> And we have to fix the case A, then we shall do it right away along
> with your current fixes.
A SET AUTOCOMMIT=1 does not commit a transaction started with BEGIN
and therefore there is nothing in binlog, either engine. This
contradicts to the current docs.
The commit was always executed, and that was not the problem. As you can
see from the trace I sent you, the engine is committed. The problem is
that binlog_commit() was called with thd->options set to the *new*
values, and therefore decided that there were nothing to commit. Now,
binlog_commit() is called with the *original* values in thd->options,
which means that it does recognize the commit as a real commit, and
commits the transaction cache to the binary log.
Best wishes,
Mats Kindahl
--
Mats Kindahl
Lead Software Developer
Replication Team
MySQL AB, www.mysql.com
