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;
begin;
insert into t1 values (1);
SET AUTOCOMMIT=1;
The last `SET AUTOCOMMIT=1' does not commit.
Does it commit in your env?
If not, is it a bug?
If yes, do you think it should be fixed along the current bug fixes?
cheers,
Andrei
