Mats,
The patch is okay after you helped me to find the right docs sources.
> 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.
Actully it's not. I got trapped with reading obsolate docs version...
(sigh, a lesson to me).
>>>>>> >
>>>>>> > 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)
>
that's what i missed to find.
>>
>>> 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.
It can be seen from the result file, right. But I'd rather to have
seen the updated docs.
Thanks for this work!
Andrei
