2003-01-18 15:39:21 +01:00
stop slave;
2003-01-14 10:27:26 +01:00
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
2003-01-18 15:39:21 +01:00
start slave;
First commit for fixing BUG#1100
"LOAD DATA INFILE is badly filtered by binlog-*-db rules".
There will probably be a second final one to merge Dmitri's changes
to rpl_log.result and mine.
2 new tests:
rpl_loaddata_rule_m : test of logging of LOAD DATA INFILE when the master has binlog-*-db rules,
rpl_loaddata_rule_s : test of logging of LOAD DATA INFILE when the slave has binlog-*-db rules and --log-slave-updates.
mysql-test/r/rpl_loaddata.result:
Test that logging of LOAD DATA INFILE is done on the slave
mysql-test/t/rpl_loaddata.test:
Test that logging of LOAD DATA is done on the slave
sql/log.cc:
debug info
sql/log_event.cc:
* Append_block, Exec_load and Delete_file now have a member 'db' like Create_file.
This member is filled by mysql_load(). It is used for filtering by binlog-*-db rules,
that's all. It's not written to the binlog, and so can't be read from the binlog.
In other words, that's temporary info which is stored in the event and lost when
it is written and deleted.
* Better error messages in Append_block et al. events.
* The slave now logs (log-slave-updates) the Create_file et al. events in mysql_load()
(they are not directly copied from the events in the relay log, because this
prevented filtering by binlog-*-db rules). Before, mysql_load() in the slave
did no logging, now it does the logging, as in any regular thread.
sql/log_event.h:
New member 'db' for Append_block et al. events.
sql/slave.cc:
Removed useless code. Why was it useless:
- CREATE_FILE_EVENT is not defined in 3.23. It appeared in 4.0.
- in queue_old_event(), which is called only if the master is 3.23, we had a
case CREATE_FILE_EVENT:
so this case can be removed.
- this case was the only caller of process_io_create_file() so this function
can be removed.
sql/sql_load.cc:
Pass the db to events, so that they can be well filtered.
sql/sql_repl.cc:
Pass the db to events so that they can be well filtered.
2003-08-20 23:24:45 +02:00
reset master;
WL#3146 "less locking in auto_increment":
this is a cleanup patch for our current auto_increment handling:
new names for auto_increment variables in THD, new methods to manipulate them
(see sql_class.h), some move into handler::, causing less backup/restore
work when executing substatements.
This makes the logic hopefully clearer, less work is is needed in
mysql_insert().
By cleaning up, using different variables for different purposes (instead
of one for 3 things...), we fix those bugs, which someone may want to fix
in 5.0 too:
BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
statement-based"
BUG#20341 "stored function inserting into one auto_increment puts bad
data in slave"
BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE"
(now if a row is updated, LAST_INSERT_ID() will return its id)
and re-fixes:
BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT"
(already fixed differently by Ramil in 4.1)
Test of documented behaviour of mysql_insert_id() (there was no test).
The behaviour changes introduced are:
- LAST_INSERT_ID() now returns "the first autogenerated auto_increment value
successfully inserted", instead of "the first autogenerated auto_increment
value if any row was successfully inserted", see auto_increment.test.
Same for mysql_insert_id(), see mysql_client_test.c.
- LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY
UPDATE, see auto_increment.test. Same for mysql_insert_id(), see
mysql_client_test.c.
- LAST_INSERT_ID() does not change if no autogenerated value was successfully
inserted (it used to then be 0), see auto_increment.test.
- if in INSERT SELECT no autogenerated value was successfully inserted,
mysql_insert_id() now returns the id of the last inserted row (it already
did this for INSERT VALUES), see mysql_client_test.c.
- if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X
(it already did this for INSERT VALUES), see mysql_client_test.c.
- NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE,
the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID
influences not only the first row now.
Additionally, when unlocking a table we check that the thread is not keeping
a next_insert_id (as the table is unlocked that id is potentially out-of-date);
forgetting about this next_insert_id is done in a new
handler::ha_release_auto_increment().
Finally we prepare for engines capable of reserving finite-length intervals
of auto_increment values: we store such intervals in THD. The next step
(to be done by the replication team in 5.1) is to read those intervals from
THD and actually store them in the statement-based binary log. NDB
will be a good engine to test that.
mysql-test/extra/binlog_tests/binlog.test:
Testing that if INSERT_ID is set to a value too big for the
column's type, the binlogged INSERT_ID is the truncated value
(important if slave has a column of a "wider" numeric type).
Testing binlogging of INSERT_ID with INSERT DELAYED, to be sure that
we binlog an INSERT_ID event only for the delayed rows which use one.
mysql-test/extra/rpl_tests/rpl_insert_id.test:
Testcase for BUG#20339 "stored procedure using
LAST_INSERT_ID() does not replicate statement-based".
Testcase for BUG#20341 "stored function inserting into one
auto_increment puts bad data in slave".
mysql-test/extra/rpl_tests/rpl_loaddata.test:
Test that LOAD DATA INFILE sets a value for a future LAST_INSERT_ID().
mysql-test/r/auto_increment.result:
behaviour change: when INSERT totally fails (not even succeeds
partially and then rolls back), don't change last_insert_id().
Behaviour change: LAST_INSERT_ID() is now the first successfully inserted,
autogenerated, id.
Behaviour change: if INSERT ON DUPLICATE KEY UPDATE, if the table has auto_increment
and a row is updated, then LAST_INSERT_ID() returns the id of this row.
mysql-test/r/binlog_row_binlog.result:
result update
mysql-test/r/binlog_stm_binlog.result:
result update
mysql-test/r/insert.result:
result update
mysql-test/r/rpl_insert_id.result:
result update
mysql-test/r/rpl_loaddata.result:
result update
mysql-test/r/rpl_ndb_auto_inc.result:
ndb's behaviour is now like other engines wrt SET INSERT_ID
in a multi-row INSERT:
- with INSERT IGNORE: the id passed in SET INSERT_ID is re-used until
a row succeeds.
- generally, SET INSERT_ID sets the first value and other values are
simply computed from this first value, instead of previously where
the 2nd and subsequent values where not influenced by SET INSERT_ID;
this good change is due to the removal of "thd->next_insert_id=0"
from ha_ndbcluster.
mysql-test/t/auto_increment.test:
A testcase of BUG#19243: if ON DUPLICATE KEY UPDATE updates a row,
LAST_INSERT_ID() now returns the id of the row.
Test of new behaviour of last_insert_id() when no autogenerated value was
inserted, or when only some autogenerated value (not the first of them) was
inserted.
mysql-test/t/insert.test:
testing INSERT IGNORE re-using generated values
sql/ha_federated.cc:
update for new variables.
sql/ha_ndbcluster.cc:
handler::auto_increment_column_changed not needed, equivalent to
(insert_id_for_cur_row > 0).
thd->next_insert_id=0 not needed anymore; it was used to force
handler::update_auto_increment() to call ha_ndbcluster::get_auto_increment()
for each row of a multi-row INSERT, now this happens naturally
because NDB says "I have reserved you *one* value" in get_auto_increment(),
so handler::update_auto_increment() calls again for next row.
sql/handler.cc:
More comments, use of new methods and variables. Hopes to be clearer
than current code.
thd->prev_insert_id not in THD anymore: it is managed locally by inserters
(like mysql_insert()).
THD::clear_next_insert_id is now equivalent to
handler::next_insert_id > 0.
get_auto_increment() reserves an interval of values from the engine,
uses this interval for next rows of the statement, until interval
is exhausted then it asks for another interval (of a bigger size
than the first one; size doubles until reaching 65535 then it stays constant).
If doing statement-based binlogging, intervals are remembered in a list
for storage in the binlog.
For "forced" insert_id values (SET INSERT_ID or replication slave),
forced_auto_inc_intervals is non-empty and the handler takes its intervals
from there, without calling get_auto_increment().
ha_release_auto_increment() resets the handler's auto_increment variables;
it calls release_auto_increment() which is handler-dependent and
serves to return to the engine any unused tail of the last used
interval.
If ending a statement, next_insert_id>0 means that autoinc values have been
generated or taken from the master's binlog (in a replication slave) so
we clear those values read from binlog, so that next top- or sub-
statement does not use them.
sql/handler.h:
handler::auto_increment_changed can be replaced by
(handler::insert_id_for_cur_row > 0).
THD::next_insert_id moves into handler (more natural, and prepares
for the day when we'll support a single statement inserting into
two tables - "multi-table INSERT" like we have UPDATE - will this
happen?).
This move makes the backup/restore of THD::next_insert_id when entering
a substatement unneeded, as each substatement has its own handler
objects.
sql/item_func.cc:
new names for variables.
For the setting of what mysql_insert_id() will return to the client,
LAST_INSERT_ID(X) used to simply pretend that the generated autoinc
value for the current row was X, but this led to having no reliable
way to know the really generated value, so we now have a bool:
thd->arg_of_last_insert_id_function which enables us to know that
LAST_INSERT_ID(X) was called (and then X can be found in
thd->first_successful_insert_id_in_prev_stmt).
sql/log.cc:
new variable names for insert_ids. Removing some unused variables in the slow
log.
sql/log_event.cc:
new variable names, comments. Preparing for when master's won't binlog
LAST_INSERT_ID if it was 0.
sql/set_var.cc:
new variable names.
The last change repeats how Bar fixed BUG#20392
"INSERT_ID session variable has weird value" in 5.0.
sql/sql_class.cc:
new variables for insert_id. In THD::cleanup_after_query() we fix
BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
statement-based" (will one want to fix it in 5.0?). Many comments
about what stored functions do to auto_increment.
In reset|restore_sub_statement_state(), we need to backup less
auto_inc variables as some of them have moved to the handler;
we backup/restore those which are about the current top- or sub-
statement, *not* those about the statement-based binlog
(which evolve as the top- and sub-statement execute).
Because we split THD::last_insert_id into
THD::first_successful_insert_id_in_prev_stmt and
THD::auto_inc_intervals_for_binlog (among others), we fix
BUG#20341 "stored function inserting into one auto_increment
puts bad data in slave": indeed we can afford to not backup/restore
THD::auto_inc_intervals_for_binlog (which fixes the bug) while still
backing up / restoring THD::first_successful_insert_id_in_prev_stmt
(ensuring that the top-level LAST_INSERT_ID() is not affected by INSERTs
done by sub-statements, as is desirable and tested in rpl_insert_id.test).
sql/sql_class.h:
new variables and methods for auto_increment.
Some THD members move into handler (those which are really about
the table being inserted), some stay in THD (those which are
about what a future LAST_INSERT_ID() should return, or about
what should be stored into the statement-based binlog).
THD::next_insert_id moves to handler::.
THD::clear_next_insert_id removed (had become equivalent
to next_insert_id > 0).
THD::last_insert_id becomes four:
THD::first_successful_insert_id_in_cur_stmt,
THD::auto_inc_intervals_for_binlog,
handler::insert_id_for_cur_row,
THD::first_successful_insert_id_in_prev_stmt.
THD::current_insert_id becomes:
THD::first_successful_insert_id_in_prev_stmt_for_binlog
THD::prev_insert_id is removed, handler can just use
handler::insert_id_for_cur_row instead (which is more accurate:
for the first row, prev_insert_id was set before get_auto_increment
was called, so was 0, causing a call to
get_auto_increment() for the 2nd row if the 1st row fails;
here we don't need the call as insert_id_for_cur_row has
the value of the first row).
THD::last_insert_id_used becomes: stmt_depends_on_first_row_in_prev_stmt
THD::insert_id_used is removed (equivalent to
auto_inc_intervals_for_binlog non empty).
The interval returned by get_auto_increment() and currently being
consumed is handler::auto_inc_interval_for_cur_row.
Comments to explain each of them.
select_insert::last_insert_id becomes autoinc_value_of_last_inserted_row.
sql/sql_insert.cc:
the "id" variable is not changed for each row now; it used to compensate for
this contradiction:
- thd->last_insert_id supposed job was to keep the id of the first row
- but it was updated for every row
- so mysql_insert() made sure to catch its first value and restore it at the end of stmt.
Now THD keeps the first value in first_successful_insert_id_in_cur_stmt,
and value of the row in insert_id_for_cur_row. So "id" only serves to fill
mysql_insert_id(), as depending on some conditions, "id" must be different
values.
Prev_insert_id moves from THD to write_record().
We now set LAST_INSERT_ID() in ON DUPLICATE KEY UPDATE too (BUG#19243).
In an INSERT DELAYED, we still "reset auto-increment caching" but differently
(by calling ha_release_auto_increment()).
sql/sql_load.cc:
no need to fiddle with "id", THD maintains
THD::first_successful_insert_id_in_cur_stmt by itself and correctly now.
ha_release_auto_increment() is now (logically) called before we unlock
the table.
sql/sql_parse.cc:
update to new variable names.
Assertion that reset_thd_for_next_command() is not called for every
substatement of a routine (I'm not against it, but if we do this change,
statement-based binlogging needs some adjustments).
sql/sql_select.cc:
update for new variable names
sql/sql_table.cc:
next_insert_id not needed in mysql_alter_table(), THD manages.
sql/sql_update.cc:
update for new variable names.
Even though this is UPDATE, an insert id can be generated (by
LAST_INSERT_ID(X)) and should be recorded because mysql_insert_id() wants
to know about it.
sql/structs.h:
A class for "discrete" intervals (intervals of integer numbers with a certain
increment between them): Discrete_interval, and a class for a list of such
intervals: Discrete_intervals_list
tests/mysql_client_test.c:
tests of behaviour of mysql_insert_id(): there were no such tests, while in
our manual we document its behaviour. In comments you'll notice the behaviour
changes introduced (there are 5).
2006-07-09 17:52:19 +02:00
select last_insert_id();
last_insert_id()
0
2003-01-14 10:27:26 +01:00
create table t1(a int not null auto_increment, b int, primary key(a) );
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1;
WL#3146 "less locking in auto_increment":
this is a cleanup patch for our current auto_increment handling:
new names for auto_increment variables in THD, new methods to manipulate them
(see sql_class.h), some move into handler::, causing less backup/restore
work when executing substatements.
This makes the logic hopefully clearer, less work is is needed in
mysql_insert().
By cleaning up, using different variables for different purposes (instead
of one for 3 things...), we fix those bugs, which someone may want to fix
in 5.0 too:
BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
statement-based"
BUG#20341 "stored function inserting into one auto_increment puts bad
data in slave"
BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE"
(now if a row is updated, LAST_INSERT_ID() will return its id)
and re-fixes:
BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT"
(already fixed differently by Ramil in 4.1)
Test of documented behaviour of mysql_insert_id() (there was no test).
The behaviour changes introduced are:
- LAST_INSERT_ID() now returns "the first autogenerated auto_increment value
successfully inserted", instead of "the first autogenerated auto_increment
value if any row was successfully inserted", see auto_increment.test.
Same for mysql_insert_id(), see mysql_client_test.c.
- LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY
UPDATE, see auto_increment.test. Same for mysql_insert_id(), see
mysql_client_test.c.
- LAST_INSERT_ID() does not change if no autogenerated value was successfully
inserted (it used to then be 0), see auto_increment.test.
- if in INSERT SELECT no autogenerated value was successfully inserted,
mysql_insert_id() now returns the id of the last inserted row (it already
did this for INSERT VALUES), see mysql_client_test.c.
- if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X
(it already did this for INSERT VALUES), see mysql_client_test.c.
- NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE,
the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID
influences not only the first row now.
Additionally, when unlocking a table we check that the thread is not keeping
a next_insert_id (as the table is unlocked that id is potentially out-of-date);
forgetting about this next_insert_id is done in a new
handler::ha_release_auto_increment().
Finally we prepare for engines capable of reserving finite-length intervals
of auto_increment values: we store such intervals in THD. The next step
(to be done by the replication team in 5.1) is to read those intervals from
THD and actually store them in the statement-based binary log. NDB
will be a good engine to test that.
mysql-test/extra/binlog_tests/binlog.test:
Testing that if INSERT_ID is set to a value too big for the
column's type, the binlogged INSERT_ID is the truncated value
(important if slave has a column of a "wider" numeric type).
Testing binlogging of INSERT_ID with INSERT DELAYED, to be sure that
we binlog an INSERT_ID event only for the delayed rows which use one.
mysql-test/extra/rpl_tests/rpl_insert_id.test:
Testcase for BUG#20339 "stored procedure using
LAST_INSERT_ID() does not replicate statement-based".
Testcase for BUG#20341 "stored function inserting into one
auto_increment puts bad data in slave".
mysql-test/extra/rpl_tests/rpl_loaddata.test:
Test that LOAD DATA INFILE sets a value for a future LAST_INSERT_ID().
mysql-test/r/auto_increment.result:
behaviour change: when INSERT totally fails (not even succeeds
partially and then rolls back), don't change last_insert_id().
Behaviour change: LAST_INSERT_ID() is now the first successfully inserted,
autogenerated, id.
Behaviour change: if INSERT ON DUPLICATE KEY UPDATE, if the table has auto_increment
and a row is updated, then LAST_INSERT_ID() returns the id of this row.
mysql-test/r/binlog_row_binlog.result:
result update
mysql-test/r/binlog_stm_binlog.result:
result update
mysql-test/r/insert.result:
result update
mysql-test/r/rpl_insert_id.result:
result update
mysql-test/r/rpl_loaddata.result:
result update
mysql-test/r/rpl_ndb_auto_inc.result:
ndb's behaviour is now like other engines wrt SET INSERT_ID
in a multi-row INSERT:
- with INSERT IGNORE: the id passed in SET INSERT_ID is re-used until
a row succeeds.
- generally, SET INSERT_ID sets the first value and other values are
simply computed from this first value, instead of previously where
the 2nd and subsequent values where not influenced by SET INSERT_ID;
this good change is due to the removal of "thd->next_insert_id=0"
from ha_ndbcluster.
mysql-test/t/auto_increment.test:
A testcase of BUG#19243: if ON DUPLICATE KEY UPDATE updates a row,
LAST_INSERT_ID() now returns the id of the row.
Test of new behaviour of last_insert_id() when no autogenerated value was
inserted, or when only some autogenerated value (not the first of them) was
inserted.
mysql-test/t/insert.test:
testing INSERT IGNORE re-using generated values
sql/ha_federated.cc:
update for new variables.
sql/ha_ndbcluster.cc:
handler::auto_increment_column_changed not needed, equivalent to
(insert_id_for_cur_row > 0).
thd->next_insert_id=0 not needed anymore; it was used to force
handler::update_auto_increment() to call ha_ndbcluster::get_auto_increment()
for each row of a multi-row INSERT, now this happens naturally
because NDB says "I have reserved you *one* value" in get_auto_increment(),
so handler::update_auto_increment() calls again for next row.
sql/handler.cc:
More comments, use of new methods and variables. Hopes to be clearer
than current code.
thd->prev_insert_id not in THD anymore: it is managed locally by inserters
(like mysql_insert()).
THD::clear_next_insert_id is now equivalent to
handler::next_insert_id > 0.
get_auto_increment() reserves an interval of values from the engine,
uses this interval for next rows of the statement, until interval
is exhausted then it asks for another interval (of a bigger size
than the first one; size doubles until reaching 65535 then it stays constant).
If doing statement-based binlogging, intervals are remembered in a list
for storage in the binlog.
For "forced" insert_id values (SET INSERT_ID or replication slave),
forced_auto_inc_intervals is non-empty and the handler takes its intervals
from there, without calling get_auto_increment().
ha_release_auto_increment() resets the handler's auto_increment variables;
it calls release_auto_increment() which is handler-dependent and
serves to return to the engine any unused tail of the last used
interval.
If ending a statement, next_insert_id>0 means that autoinc values have been
generated or taken from the master's binlog (in a replication slave) so
we clear those values read from binlog, so that next top- or sub-
statement does not use them.
sql/handler.h:
handler::auto_increment_changed can be replaced by
(handler::insert_id_for_cur_row > 0).
THD::next_insert_id moves into handler (more natural, and prepares
for the day when we'll support a single statement inserting into
two tables - "multi-table INSERT" like we have UPDATE - will this
happen?).
This move makes the backup/restore of THD::next_insert_id when entering
a substatement unneeded, as each substatement has its own handler
objects.
sql/item_func.cc:
new names for variables.
For the setting of what mysql_insert_id() will return to the client,
LAST_INSERT_ID(X) used to simply pretend that the generated autoinc
value for the current row was X, but this led to having no reliable
way to know the really generated value, so we now have a bool:
thd->arg_of_last_insert_id_function which enables us to know that
LAST_INSERT_ID(X) was called (and then X can be found in
thd->first_successful_insert_id_in_prev_stmt).
sql/log.cc:
new variable names for insert_ids. Removing some unused variables in the slow
log.
sql/log_event.cc:
new variable names, comments. Preparing for when master's won't binlog
LAST_INSERT_ID if it was 0.
sql/set_var.cc:
new variable names.
The last change repeats how Bar fixed BUG#20392
"INSERT_ID session variable has weird value" in 5.0.
sql/sql_class.cc:
new variables for insert_id. In THD::cleanup_after_query() we fix
BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
statement-based" (will one want to fix it in 5.0?). Many comments
about what stored functions do to auto_increment.
In reset|restore_sub_statement_state(), we need to backup less
auto_inc variables as some of them have moved to the handler;
we backup/restore those which are about the current top- or sub-
statement, *not* those about the statement-based binlog
(which evolve as the top- and sub-statement execute).
Because we split THD::last_insert_id into
THD::first_successful_insert_id_in_prev_stmt and
THD::auto_inc_intervals_for_binlog (among others), we fix
BUG#20341 "stored function inserting into one auto_increment
puts bad data in slave": indeed we can afford to not backup/restore
THD::auto_inc_intervals_for_binlog (which fixes the bug) while still
backing up / restoring THD::first_successful_insert_id_in_prev_stmt
(ensuring that the top-level LAST_INSERT_ID() is not affected by INSERTs
done by sub-statements, as is desirable and tested in rpl_insert_id.test).
sql/sql_class.h:
new variables and methods for auto_increment.
Some THD members move into handler (those which are really about
the table being inserted), some stay in THD (those which are
about what a future LAST_INSERT_ID() should return, or about
what should be stored into the statement-based binlog).
THD::next_insert_id moves to handler::.
THD::clear_next_insert_id removed (had become equivalent
to next_insert_id > 0).
THD::last_insert_id becomes four:
THD::first_successful_insert_id_in_cur_stmt,
THD::auto_inc_intervals_for_binlog,
handler::insert_id_for_cur_row,
THD::first_successful_insert_id_in_prev_stmt.
THD::current_insert_id becomes:
THD::first_successful_insert_id_in_prev_stmt_for_binlog
THD::prev_insert_id is removed, handler can just use
handler::insert_id_for_cur_row instead (which is more accurate:
for the first row, prev_insert_id was set before get_auto_increment
was called, so was 0, causing a call to
get_auto_increment() for the 2nd row if the 1st row fails;
here we don't need the call as insert_id_for_cur_row has
the value of the first row).
THD::last_insert_id_used becomes: stmt_depends_on_first_row_in_prev_stmt
THD::insert_id_used is removed (equivalent to
auto_inc_intervals_for_binlog non empty).
The interval returned by get_auto_increment() and currently being
consumed is handler::auto_inc_interval_for_cur_row.
Comments to explain each of them.
select_insert::last_insert_id becomes autoinc_value_of_last_inserted_row.
sql/sql_insert.cc:
the "id" variable is not changed for each row now; it used to compensate for
this contradiction:
- thd->last_insert_id supposed job was to keep the id of the first row
- but it was updated for every row
- so mysql_insert() made sure to catch its first value and restore it at the end of stmt.
Now THD keeps the first value in first_successful_insert_id_in_cur_stmt,
and value of the row in insert_id_for_cur_row. So "id" only serves to fill
mysql_insert_id(), as depending on some conditions, "id" must be different
values.
Prev_insert_id moves from THD to write_record().
We now set LAST_INSERT_ID() in ON DUPLICATE KEY UPDATE too (BUG#19243).
In an INSERT DELAYED, we still "reset auto-increment caching" but differently
(by calling ha_release_auto_increment()).
sql/sql_load.cc:
no need to fiddle with "id", THD maintains
THD::first_successful_insert_id_in_cur_stmt by itself and correctly now.
ha_release_auto_increment() is now (logically) called before we unlock
the table.
sql/sql_parse.cc:
update to new variable names.
Assertion that reset_thd_for_next_command() is not called for every
substatement of a routine (I'm not against it, but if we do this change,
statement-based binlogging needs some adjustments).
sql/sql_select.cc:
update for new variable names
sql/sql_table.cc:
next_insert_id not needed in mysql_alter_table(), THD manages.
sql/sql_update.cc:
update for new variable names.
Even though this is UPDATE, an insert id can be generated (by
LAST_INSERT_ID(X)) and should be recorded because mysql_insert_id() wants
to know about it.
sql/structs.h:
A class for "discrete" intervals (intervals of integer numbers with a certain
increment between them): Discrete_interval, and a class for a list of such
intervals: Discrete_intervals_list
tests/mysql_client_test.c:
tests of behaviour of mysql_insert_id(): there were no such tests, while in
our manual we document its behaviour. In comments you'll notice the behaviour
changes introduced (there are 5).
2006-07-09 17:52:19 +02:00
select last_insert_id();
last_insert_id()
1
2003-04-03 18:54:08 +02:00
create temporary table t2 (day date,id int(9),category enum('a','b','c'),name varchar(60));
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata2.dat' into table t2 fields terminated by ',' optionally enclosed by '%' escaped by '@' lines terminated by '\n##\n' starting by '>' ignore 1 lines;
2003-04-03 18:54:08 +02:00
create table t3 (day date,id int(9),category enum('a','b','c'),name varchar(60));
insert into t3 select * from t2;
2003-01-14 10:27:26 +01:00
select * from t1;
a b
1 10
2 15
2003-04-03 18:54:08 +02:00
select * from t3;
day id category name
2003-02-22 2461 b a a a @ %
2003-03-22 2161 c asdf
2003-09-25 00:14:46 +02:00
2003-03-22 2416 a bbbbb
2 minor edits, plus
fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning"
and
fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog".
Now we don't always write the non-trans update immediately to the binlog;
if there is something in the binlog cache we write it to the binlog cache
(because the non-trans update could depend on a trans table which was modified
earlier in the transaction); then in case of ROLLBACK, we write the binlog
cache to the binlog, wrapped with BEGIN/ROLLBACK.
This guarantees that the slave does the same updates.
For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it
to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated,
we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction
terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog
(because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO
SAVEPOINT in the binlog.
Apart from this rare case of updates of mixed table types in transaction, the
usual way is still clear the binlog cache at ROLLBACK, or chop it at
ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which
is fine).
Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM".
client/mysqldump.c:
Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each.
mysql-test/r/rpl_loaddata.result:
result update
mysql-test/t/rpl_loaddata.test:
minor edit: simplifying the test.
sql/handler.cc:
Fix for BUG#873. See comments in code, and the description of the changeset.
sql/log.cc:
* Previously, if a query updated a non-transactional table we wrote it immediately
to the real binlog. This causes a bug when the update is done inside a transaction
and uses the content of an updated transactional table (because this makes
a wrong order of queries in the binlog). So if the binlog cache is not empty,
we write the query to the binlog cache; otherwise we can write it to the binlog.
* Previously, when we flushed the binlog cache to the binlog, we wrapped it
with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle
transactions which update both transactional and non-transactional tables.
sql/log_event.cc:
The slave thread can leave a transaction if COMMIT or if ROLLBACK.
sql/sql_class.h:
prototype
sql/sql_insert.cc:
Fix for BUG#1113:
this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE.
sql/sql_parse.cc:
Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
show master status;
2003-11-20 20:49:05 +01:00
File Position Binlog_Do_DB Binlog_Ignore_DB
Fixing problems I identified in my auto_increment work pushed in July
(as part of the auto_increment cleanup of WL#3146; let's not be
sad, that monster push still removed serious bugs):
one problem with INSERT DELAYED (unexpected interval releases),
one with stored functions (wrong auto_inc binlogging).
These bugs were not released.
mysql-test/extra/binlog_tests/binlog_insert_delayed.test:
more tests of binlogging of INSERT DELAYED: with multi-row INSERTs.
I identified why sleeps are needed to get a repeatable row-based
binlogged: because without sleeps rows sometimes get groupped
and so generate different row based events.
mysql-test/extra/rpl_tests/rpl_foreign_key.test:
don't forget to drop tables on slave too, otherwise it leaves
an orphan innodb table leading to rpl_insert_id failing sometimes
(like in pushbuild "sapsrv2 -max").
mysql-test/extra/rpl_tests/rpl_insert_id.test:
testing that if some statement does not update any row, it does
not pollute the auto_inc binlog variables of the next statement;
the test has to use stored procedures because with plain statements,
mysql_reset_thd_for_next_command() does the resetting (and thus
there is no problem); mysql_reset_thd_for_next_command() is not
called inside routines.
mysql-test/r/binlog_row_binlog.result:
result additions
mysql-test/r/binlog_statement_insert_delayed.result:
result additions
mysql-test/r/binlog_stm_binlog.result:
result additions
mysql-test/r/rpl_insert_id.result:
result additions
mysql-test/r/rpl_loaddata.result:
With the change to log.cc reverted, the result changes and is better:
the change to log.cc had caused some INSERT_ID events to disappear
though they were necessary (but testsuite could not catch that because
it's single-threaded).
mysql-test/r/rpl_ndb_insert_ignore.result:
NDB is now like other engines regarding INSERT IGNORE: autoincrement
values which caused a duplicate key are re-used for next row, not lost.
rpl_ndb_insert_ignore.result is now identical to rpl_insert_ignore.result.
sql/log.cc:
LOAD DATA INFILE is binlogged as several events, and the last of them must
have the auto_inc id. So it's wrong to reset the auto_inc id after every
binlog write (because then it's lost after the first event of LOAD
DATA INFILE and so missing for the last one)/
Another problem: MYSQL_LOG::write() is not always called (for example
if no row was updated), so we were missing reset in some cases.
sql/sp_head.cc:
SELECT func1(),func2() generates two binlog events, so needs to
clear auto_increment binlog variables after each binlog event
(it would be more natural to clear them in the log write code,
but LOAD DATA INFILE would suffer from this see the cset comment
for log.cc). Without the clearing, the problem is:
> exec func1()
>> call cleanup_after_query() (which does not clear our vars here)
>> binlog SELECT func1()
<
> exec func2()
and so SELECT func2() is binlogged with the auto_inc of SELECT func1().
sql/sql_class.cc:
after every statement we should clear auto_inc variables used for
binlogging, except if this was a function/trigger (in which case
it may be "INSERT SELECT func()", where the cleanup_after_query()
executed in func() should not reset the auto_inc binlog variables
as they'll be necessary when binlogging the INSERT SELECT later).
sql/sql_insert.cc:
- as INSERT DELAYED uses the same TABLE object as the delayed_insert
system thread, we should not call ha_release_auto_increment()
from INSERT DELAYED (and btw it's logical as we reserve nothing
as we don't perform the insert). Calling the function caused us to
release values being used by the delayed_insert thread.
So I do the call only if this is a non-DELAYED INSERT.
- Assuming two INSERT DELAYED which get grouped by the delayed_insert
thread, the second may use values reserved by the first, which is ok
per se, but is a problem in statement-based binlogging:
the 2nd INSERT gets binlogged with the "interval start" value
of the first INSERT (=> duplicate error in slave).
- no reason to ha_release_auto_increment() after every inserted row
in INSERT SELECT; more efficient to do it only when the statement ends
sql/sql_parse.cc:
a comment
2006-09-12 15:42:13 +02:00
slave-bin.000001 1276
2003-01-14 10:27:26 +01:00
drop table t1;
2003-04-03 18:54:08 +02:00
drop table t2;
drop table t3;
-- Waiting for Monty's approval before push --
Bug 571: play LOAD DATA INFILE the same way on the slave as it was on the master:
if it was with IGNORE, do it with IGNORE,
if it was with REPLACE, do it with REPLACE,
and (the change) if it was with nothing, do it with nothing (not with IGNORE !!).
Bug 573: print a proper error message in case of duplicate entry in LOAD DATA INFILE
on the slave, i.e. a message where the keyname and key value appear :
'Duplicate entry '1' for key 1' and not 'Duplicate entry '%-.64s' for key %d'
mysql-test/r/rpl_loaddata.result:
result update
mysql-test/t/rpl_loaddata.test:
check if duplicate entries on the slave trigger an error
when the slave replicates LOAD DATA INFILE (without IGNORE or REPLACE)
(bug 571).
sql/log_event.cc:
Bug 571: play LOAD DATA INFILE the same way on the slave as it was on the master:
if it was with IGNORE, do it with IGNORE,
if it was with REPLACE, do it with REPLACE,
and (the change) if it was with nothing, do it with nothing (not with IGNORE !!).
Bug 573: print a proper error message in case of duplicate entry in LOAD DATA INFILE
on the slave, i.e. a message where the keyname and key value appear :
'Duplicate entry '1' for key 1' and not 'Duplicate entry '%-.64s' for key %d'
2003-06-03 15:47:29 +02:00
create table t1(a int, b int, unique(b));
insert into t1 values(1,10);
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1;
2003-08-04 10:59:44 +02:00
set global sql_slave_skip_counter=1;
start slave;
show slave status;
2003-11-20 20:07:25 +01:00
Slave_IO_State Master_Host Master_User Master_Port Connect_Retry Master_Log_File Read_Master_Log_Pos Relay_Log_File Relay_Log_Pos Relay_Master_Log_File Slave_IO_Running Slave_SQL_Running Replicate_Do_DB Replicate_Ignore_DB Replicate_Do_Table Replicate_Ignore_Table Replicate_Wild_Do_Table Replicate_Wild_Ignore_Table Last_Errno Last_Error Skip_Counter Exec_Master_Log_Pos Relay_Log_Space Until_Condition Until_Log_File Until_Log_Pos Master_SSL_Allowed Master_SSL_CA_File Master_SSL_CA_Path Master_SSL_Cert Master_SSL_Cipher Master_SSL_Key Seconds_Behind_Master
Fixing problems I identified in my auto_increment work pushed in July
(as part of the auto_increment cleanup of WL#3146; let's not be
sad, that monster push still removed serious bugs):
one problem with INSERT DELAYED (unexpected interval releases),
one with stored functions (wrong auto_inc binlogging).
These bugs were not released.
mysql-test/extra/binlog_tests/binlog_insert_delayed.test:
more tests of binlogging of INSERT DELAYED: with multi-row INSERTs.
I identified why sleeps are needed to get a repeatable row-based
binlogged: because without sleeps rows sometimes get groupped
and so generate different row based events.
mysql-test/extra/rpl_tests/rpl_foreign_key.test:
don't forget to drop tables on slave too, otherwise it leaves
an orphan innodb table leading to rpl_insert_id failing sometimes
(like in pushbuild "sapsrv2 -max").
mysql-test/extra/rpl_tests/rpl_insert_id.test:
testing that if some statement does not update any row, it does
not pollute the auto_inc binlog variables of the next statement;
the test has to use stored procedures because with plain statements,
mysql_reset_thd_for_next_command() does the resetting (and thus
there is no problem); mysql_reset_thd_for_next_command() is not
called inside routines.
mysql-test/r/binlog_row_binlog.result:
result additions
mysql-test/r/binlog_statement_insert_delayed.result:
result additions
mysql-test/r/binlog_stm_binlog.result:
result additions
mysql-test/r/rpl_insert_id.result:
result additions
mysql-test/r/rpl_loaddata.result:
With the change to log.cc reverted, the result changes and is better:
the change to log.cc had caused some INSERT_ID events to disappear
though they were necessary (but testsuite could not catch that because
it's single-threaded).
mysql-test/r/rpl_ndb_insert_ignore.result:
NDB is now like other engines regarding INSERT IGNORE: autoincrement
values which caused a duplicate key are re-used for next row, not lost.
rpl_ndb_insert_ignore.result is now identical to rpl_insert_ignore.result.
sql/log.cc:
LOAD DATA INFILE is binlogged as several events, and the last of them must
have the auto_inc id. So it's wrong to reset the auto_inc id after every
binlog write (because then it's lost after the first event of LOAD
DATA INFILE and so missing for the last one)/
Another problem: MYSQL_LOG::write() is not always called (for example
if no row was updated), so we were missing reset in some cases.
sql/sp_head.cc:
SELECT func1(),func2() generates two binlog events, so needs to
clear auto_increment binlog variables after each binlog event
(it would be more natural to clear them in the log write code,
but LOAD DATA INFILE would suffer from this see the cset comment
for log.cc). Without the clearing, the problem is:
> exec func1()
>> call cleanup_after_query() (which does not clear our vars here)
>> binlog SELECT func1()
<
> exec func2()
and so SELECT func2() is binlogged with the auto_inc of SELECT func1().
sql/sql_class.cc:
after every statement we should clear auto_inc variables used for
binlogging, except if this was a function/trigger (in which case
it may be "INSERT SELECT func()", where the cleanup_after_query()
executed in func() should not reset the auto_inc binlog variables
as they'll be necessary when binlogging the INSERT SELECT later).
sql/sql_insert.cc:
- as INSERT DELAYED uses the same TABLE object as the delayed_insert
system thread, we should not call ha_release_auto_increment()
from INSERT DELAYED (and btw it's logical as we reserve nothing
as we don't perform the insert). Calling the function caused us to
release values being used by the delayed_insert thread.
So I do the call only if this is a non-DELAYED INSERT.
- Assuming two INSERT DELAYED which get grouped by the delayed_insert
thread, the second may use values reserved by the first, which is ok
per se, but is a problem in statement-based binlogging:
the 2nd INSERT gets binlogged with the "interval start" value
of the first INSERT (=> duplicate error in slave).
- no reason to ha_release_auto_increment() after every inserted row
in INSERT SELECT; more efficient to do it only when the statement ends
sql/sql_parse.cc:
a comment
2006-09-12 15:42:13 +02:00
# 127.0.0.1 root MASTER_PORT 1 master-bin.000001 1793 # # master-bin.000001 Yes Yes # 0 0 1793 # None 0 No #
2003-08-04 10:59:44 +02:00
set sql_log_bin=0;
delete from t1;
set sql_log_bin=1;
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1;
2003-08-04 10:59:44 +02:00
stop slave;
change master to master_user='test';
change master to master_user='root';
show slave status;
2003-11-20 20:07:25 +01:00
Slave_IO_State Master_Host Master_User Master_Port Connect_Retry Master_Log_File Read_Master_Log_Pos Relay_Log_File Relay_Log_Pos Relay_Master_Log_File Slave_IO_Running Slave_SQL_Running Replicate_Do_DB Replicate_Ignore_DB Replicate_Do_Table Replicate_Ignore_Table Replicate_Wild_Do_Table Replicate_Wild_Ignore_Table Last_Errno Last_Error Skip_Counter Exec_Master_Log_Pos Relay_Log_Space Until_Condition Until_Log_File Until_Log_Pos Master_SSL_Allowed Master_SSL_CA_File Master_SSL_CA_Path Master_SSL_Cert Master_SSL_Cipher Master_SSL_Key Seconds_Behind_Master
Fixing problems I identified in my auto_increment work pushed in July
(as part of the auto_increment cleanup of WL#3146; let's not be
sad, that monster push still removed serious bugs):
one problem with INSERT DELAYED (unexpected interval releases),
one with stored functions (wrong auto_inc binlogging).
These bugs were not released.
mysql-test/extra/binlog_tests/binlog_insert_delayed.test:
more tests of binlogging of INSERT DELAYED: with multi-row INSERTs.
I identified why sleeps are needed to get a repeatable row-based
binlogged: because without sleeps rows sometimes get groupped
and so generate different row based events.
mysql-test/extra/rpl_tests/rpl_foreign_key.test:
don't forget to drop tables on slave too, otherwise it leaves
an orphan innodb table leading to rpl_insert_id failing sometimes
(like in pushbuild "sapsrv2 -max").
mysql-test/extra/rpl_tests/rpl_insert_id.test:
testing that if some statement does not update any row, it does
not pollute the auto_inc binlog variables of the next statement;
the test has to use stored procedures because with plain statements,
mysql_reset_thd_for_next_command() does the resetting (and thus
there is no problem); mysql_reset_thd_for_next_command() is not
called inside routines.
mysql-test/r/binlog_row_binlog.result:
result additions
mysql-test/r/binlog_statement_insert_delayed.result:
result additions
mysql-test/r/binlog_stm_binlog.result:
result additions
mysql-test/r/rpl_insert_id.result:
result additions
mysql-test/r/rpl_loaddata.result:
With the change to log.cc reverted, the result changes and is better:
the change to log.cc had caused some INSERT_ID events to disappear
though they were necessary (but testsuite could not catch that because
it's single-threaded).
mysql-test/r/rpl_ndb_insert_ignore.result:
NDB is now like other engines regarding INSERT IGNORE: autoincrement
values which caused a duplicate key are re-used for next row, not lost.
rpl_ndb_insert_ignore.result is now identical to rpl_insert_ignore.result.
sql/log.cc:
LOAD DATA INFILE is binlogged as several events, and the last of them must
have the auto_inc id. So it's wrong to reset the auto_inc id after every
binlog write (because then it's lost after the first event of LOAD
DATA INFILE and so missing for the last one)/
Another problem: MYSQL_LOG::write() is not always called (for example
if no row was updated), so we were missing reset in some cases.
sql/sp_head.cc:
SELECT func1(),func2() generates two binlog events, so needs to
clear auto_increment binlog variables after each binlog event
(it would be more natural to clear them in the log write code,
but LOAD DATA INFILE would suffer from this see the cset comment
for log.cc). Without the clearing, the problem is:
> exec func1()
>> call cleanup_after_query() (which does not clear our vars here)
>> binlog SELECT func1()
<
> exec func2()
and so SELECT func2() is binlogged with the auto_inc of SELECT func1().
sql/sql_class.cc:
after every statement we should clear auto_inc variables used for
binlogging, except if this was a function/trigger (in which case
it may be "INSERT SELECT func()", where the cleanup_after_query()
executed in func() should not reset the auto_inc binlog variables
as they'll be necessary when binlogging the INSERT SELECT later).
sql/sql_insert.cc:
- as INSERT DELAYED uses the same TABLE object as the delayed_insert
system thread, we should not call ha_release_auto_increment()
from INSERT DELAYED (and btw it's logical as we reserve nothing
as we don't perform the insert). Calling the function caused us to
release values being used by the delayed_insert thread.
So I do the call only if this is a non-DELAYED INSERT.
- Assuming two INSERT DELAYED which get grouped by the delayed_insert
thread, the second may use values reserved by the first, which is ok
per se, but is a problem in statement-based binlogging:
the 2nd INSERT gets binlogged with the "interval start" value
of the first INSERT (=> duplicate error in slave).
- no reason to ha_release_auto_increment() after every inserted row
in INSERT SELECT; more efficient to do it only when the statement ends
sql/sql_parse.cc:
a comment
2006-09-12 15:42:13 +02:00
# 127.0.0.1 root MASTER_PORT 1 master-bin.000001 1828 # # master-bin.000001 No No # 0 0 1828 # None 0 No #
2003-08-04 10:59:44 +02:00
set global sql_slave_skip_counter=1;
start slave;
set sql_log_bin=0;
delete from t1;
set sql_log_bin=1;
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1;
2003-08-04 10:59:44 +02:00
stop slave;
reset slave;
show slave status;
2003-11-20 20:07:25 +01:00
Slave_IO_State Master_Host Master_User Master_Port Connect_Retry Master_Log_File Read_Master_Log_Pos Relay_Log_File Relay_Log_Pos Relay_Master_Log_File Slave_IO_Running Slave_SQL_Running Replicate_Do_DB Replicate_Ignore_DB Replicate_Do_Table Replicate_Ignore_Table Replicate_Wild_Do_Table Replicate_Wild_Ignore_Table Last_Errno Last_Error Skip_Counter Exec_Master_Log_Pos Relay_Log_Space Until_Condition Until_Log_File Until_Log_Pos Master_SSL_Allowed Master_SSL_CA_File Master_SSL_CA_Path Master_SSL_Cert Master_SSL_Cipher Master_SSL_Key Seconds_Behind_Master
2005-12-22 06:39:02 +01:00
# 127.0.0.1 root MASTER_PORT 1 4 # # No No # 0 0 0 # None 0 No #
2003-09-25 00:14:46 +02:00
reset master;
create table t2 (day date,id int(9),category enum('a','b','c'),name varchar(60),
2005-03-25 14:51:17 +01:00
unique(day)) engine=MyISAM;
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata2.dat' into table t2 fields
2003-09-25 00:14:46 +02:00
terminated by ',' optionally enclosed by '%' escaped by '@' lines terminated by
'\n##\n' starting by '>' ignore 1 lines;
2006-01-23 12:17:05 +01:00
ERROR 23000: Duplicate entry '2003-03-22' for key 'day'
2005-03-25 14:51:17 +01:00
select * from t2;
day id category name
2003-02-22 2461 b a a a @ %
2003-03-22 2161 c asdf
start slave;
select * from t2;
day id category name
2003-02-22 2461 b a a a @ %
2003-03-22 2161 c asdf
alter table t2 drop key day;
delete from t2;
2006-01-24 08:30:54 +01:00
load data infile '../std_data_ln/rpl_loaddata2.dat' into table t2 fields
2005-03-25 14:51:17 +01:00
terminated by ',' optionally enclosed by '%' escaped by '@' lines terminated by
'\n##\n' starting by '>' ignore 1 lines;
2006-01-23 12:17:05 +01:00
ERROR 23000: Duplicate entry '2003-03-22' for key 'day'
2005-03-25 14:51:17 +01:00
drop table t2;
2003-09-25 00:14:46 +02:00
drop table t2;
2006-06-10 19:35:18 +02:00
drop table t1;
