Hi Rafal, (Hi Chuck, please at bottom)
great that we agree. I have good news. Please see below.
Rafal Somla, 23.10.2009 07:39:
...
> Ingo Strüwing wrote:
...
> My proposition was based on assumption that a consistent read
> transaction would present unchanged auto_increment values even if
> concurrent INSERTS happen, similar as it is with table data.
>
> But after our discussions I see that one can not expect that to happen.
I did even prove by testing that parallel DML can increase the
auto_increment value, which the backup transaction sees.
> In that case the only "advantage" of my solution is, as you wrote, that
> AI values are nearer to the values at VP time. But I can agree that this
> is perhaps not worth the effort.
...
>> For statement based replication, it could be a problem if the slave
>> generates different auto_increment values than the master.
>>
>
> Yes, I understand now and agree - this is an issue we have to consider.
I asked the replication team about it:
[#dev 2009-10-23 09:46 CEST]
<mats> ingo, No, the auto-increment value is passed with each statement
as an Intvar_log_event before the statement that does the actual update,
so it should not pose a problem.
So it seems we are fine with the proposed solution. May I ask you for a
formal review please?
Hi Chuck,
can you please do the second review? Please have special attention to
the "/*FALLTHROUGH ...*/" comment, I put into be_default.cc. I suspect a
bug here. That area of code is not covered by tests, btw.
Regards
Ingo
--
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028
