389
389
first insert id successfully inserted by the previous stmt.
390
390
- as stmt makes progress, handler::insert_id_for_cur_row changes;
391
391
every time get_auto_increment() is called,
392
auto_inc_intervals_in_cur_stmt_for_binlog is augmented with the
393
reserved interval (if statement-based binlogging).
394
392
- at first successful insertion of an autogenerated value,
395
393
first_successful_insert_id_in_cur_stmt is set to
396
394
handler::insert_id_for_cur_row.
397
- when stmt goes to binlog,
398
auto_inc_intervals_in_cur_stmt_for_binlog is binlogged if
400
395
- when stmt ends, first_successful_insert_id_in_prev_stmt is set to
401
396
first_successful_insert_id_in_cur_stmt.
403
List of auto_increment intervals reserved by the thread so far, for
404
storage in the statement-based binlog.
405
Note that its minimum is not first_successful_insert_id_in_cur_stmt:
406
assuming a table with an autoinc column, and this happens:
407
INSERT INTO ... VALUES(3);
408
SET INSERT_ID=3; INSERT IGNORE ... VALUES (NULL);
409
then the latter INSERT will insert no rows
410
(first_successful_insert_id_in_cur_stmt == 0), but storing "INSERT_ID=3"
411
in the binlog is still needed; the list's minimum will contain 3.
414
399
uint64_t limit_found_rows;
673
658
return server_uuid;
677
There is BUG#19630 where statement-based replication of stored
678
functions/triggers with two auto_increment columns breaks.
679
We however ensure that it works when there is 0 or 1 auto_increment
680
column; our rules are
681
a) on master, while executing a top statement involving substatements,
682
first top- or sub- statement to generate auto_increment values wins the
683
exclusive right to see its values be written to binlog (the write
684
will be done by the statement or its caller), and the losers won't see
685
their values be written to binlog.
686
b) on slave, while replicating a top statement involving substatements,
687
first top- or sub- statement to need to read auto_increment values from
688
the master's binlog wins the exclusive right to read them (so the losers
689
won't read their values from binlog but instead generate on their own).
690
a) implies that we mustn't backup/restore
691
auto_inc_intervals_in_cur_stmt_for_binlog.
692
b) implies that we mustn't backup/restore auto_inc_intervals_forced.
694
If there are more than 1 auto_increment columns, then intervals for
695
different columns may mix into the
696
auto_inc_intervals_in_cur_stmt_for_binlog list, which is logically wrong,
697
but there is no point in preventing this mixing by preventing intervals
698
from the secondly inserted column to come into the list, as such
699
prevention would be wrong too.
700
What will happen in the case of
701
INSERT INTO t1 (auto_inc) VALUES(NULL);
702
where t1 has a trigger which inserts into an auto_inc column of t2, is
703
that in binlog we'll store the interval of t1 and the interval of t2 (when
704
we store intervals, soon), then in slave, t1 will use both intervals, t2
705
will use none; if t1 inserts the same number of rows as on master,
706
normally the 2nd interval will not be used by t1, which is fine. t2's
707
values will be wrong if t2's internal auto_increment counter is different
708
from what it was on master (which is likely). In 5.1, in mixed binlogging
709
mode, row-based binlogging is used for such cases where two
710
auto_increment columns are inserted.
712
661
inline void record_first_successful_insert_id_in_cur_stmt(uint64_t id_arg)
714
663
if (first_successful_insert_id_in_cur_stmt == 0)
added
removed
drizzled/session.h
