2006-02-06 18:25:12 +01:00
create table t1 (a int, b int) engine=innodb;
begin;
insert into t1 values (1,2);
commit;
2007-03-30 04:44:49 +02:00
show binlog events;
2006-02-06 18:25:12 +01:00
Log_name Pos Event_type Server_id End_log_pos Info
2007-03-30 04:44:49 +02:00
master-bin.000001 4 Format_desc 1 106 Server ver: #, Binlog ver: #
master-bin.000001 106 Query 1 213 use `test`; create table t1 (a int, b int) engine=innodb
master-bin.000001 213 Query 1 281 use `test`; BEGIN
master-bin.000001 281 Query 1 90 use `test`; insert into t1 values (1,2)
master-bin.000001 371 Xid 1 398 COMMIT /* XID */
2006-02-06 18:25:12 +01:00
drop table t1;
2005-02-23 14:55:16 +01:00
drop table if exists t1, t2;
2005-02-23 18:26:49 +01:00
reset master;
2006-08-11 03:29:25 +02:00
create table t1 (a int) engine=innodb;
2005-02-23 14:55:16 +01:00
create table t2 (a int) engine=innodb;
begin;
insert t1 values (5);
commit;
begin;
insert t2 values (5);
commit;
2007-03-29 21:38:03 +02:00
show binlog events from <binlog_start>;
2005-02-23 14:55:16 +01:00
Log_name Pos Event_type Server_id End_log_pos Info
2007-03-30 04:44:49 +02:00
master-bin.000001 # Query # # use `test`; create table t1 (a int) engine=innodb
master-bin.000001 # Query # # use `test`; create table t2 (a int) engine=innodb
master-bin.000001 # Query # # use `test`; BEGIN
master-bin.000001 # Query # # use `test`; insert t1 values (5)
2007-03-30 10:27:08 +02:00
master-bin.000001 # Xid # # COMMIT /* XID */
2007-03-30 04:44:49 +02:00
master-bin.000001 # Query # # use `test`; BEGIN
master-bin.000001 # Query # # use `test`; insert t2 values (5)
2007-03-30 10:27:08 +02:00
master-bin.000001 # Xid # # COMMIT /* XID */
2005-02-23 14:55:16 +01:00
drop table t1,t2;
2005-02-23 20:35:59 +01:00
reset master;
create table t1 (n int) engine=innodb;
begin;
commit;
drop table t1;
2007-03-29 21:38:03 +02:00
show binlog events in 'master-bin.000001' from 106;
2005-02-23 20:35:59 +01:00
Log_name Pos Event_type Server_id End_log_pos Info
2005-03-16 21:12:27 +01:00
master-bin.000001 # Query 1 # use `test`; create table t1 (n int) engine=innodb
master-bin.000001 # Query 1 # use `test`; BEGIN
master-bin.000001 # Query 1 # use `test`; insert into t1 values(100 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(99 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(98 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(97 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(96 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(95 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(94 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(93 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(92 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(91 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(90 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(89 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(88 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(87 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(86 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(85 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(84 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(83 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(82 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(81 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(80 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(79 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(78 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(77 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(76 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(75 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(74 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(73 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(72 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(71 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(70 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(69 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(68 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(67 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(66 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(65 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(64 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(63 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(62 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(61 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(60 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(59 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(58 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(57 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(56 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(55 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(54 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(53 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(52 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(51 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(50 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(49 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(48 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(47 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(46 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(45 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(44 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(43 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(42 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(41 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(40 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(39 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(38 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(37 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(36 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(35 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(34 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(33 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(32 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(31 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(30 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(29 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(28 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(27 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(26 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(25 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(24 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(23 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(22 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(21 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(20 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(19 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(18 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(17 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(16 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(15 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(14 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(13 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(12 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(11 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(10 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(9 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(8 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(7 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(6 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(5 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(4 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(3 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(2 + 4)
master-bin.000001 # Query 1 # use `test`; insert into t1 values(1 + 4)
2005-12-22 06:39:02 +01:00
master-bin.000001 # Xid 1 # COMMIT /* xid= */
2005-03-16 21:12:27 +01:00
master-bin.000001 # Rotate 1 # master-bin.000002;pos=4
2007-03-29 21:38:03 +02:00
show binlog events in 'master-bin.000002' from 106;
2005-02-23 20:35:59 +01:00
Log_name Pos Event_type Server_id End_log_pos Info
2005-03-16 21:12:27 +01:00
master-bin.000002 # Query 1 # use `test`; drop 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.
2006-07-09 17:52:19 +02:00
reset master;
create table t1 (id tinyint auto_increment primary key);
set insert_id=128;
insert into t1 values(null);
Warnings:
Warning 1264 Out of range value for column 'id' at row 1
select * from t1;
id
127
drop table t1;
2006-09-28 17:51:27 +02:00
create table t1 (a int);
create table if not exists t2 select * from t1;
create temporary table tt1 (a int);
create table if not exists t3 like tt1;
BUG#25091 (A DELETE statement to mysql database is not logged in ROW format):
With this patch, statements that change metadata (in the mysql database)
is logged as statements, while normal changes (e.g., using INSERT, DELETE,
and/or UPDATE) is logged according to the format in effect.
The log tables (i.e., general_log and slow_log) are not replicated at all.
With this patch, the following statements are replicated as statements:
GRANT, REVOKE (ALL), CREATE USER, DROP USER, and RENAME USER.
2007-02-26 10:19:08 +01:00
USE mysql;
INSERT INTO user SET host='localhost', user='@#@', password=password('Just a test');
UPDATE user SET password=password('Another password') WHERE host='localhost' AND user='@#@';
DELETE FROM user WHERE host='localhost' AND user='@#@';
use test;
2007-03-29 21:38:03 +02:00
show binlog events from <binlog_start>;
2006-09-28 17:51:27 +02:00
Log_name Pos Event_type Server_id End_log_pos Info
2007-03-30 04:44:49 +02:00
master-bin.000001 # Query # # use `test`; create table t1 (id tinyint auto_increment primary key)
master-bin.000001 # Intvar # # INSERT_ID=127
master-bin.000001 # Query # # use `test`; insert into t1 values(null)
master-bin.000001 # Query # # use `test`; drop table t1
master-bin.000001 # Query # # use `test`; create table t1 (a int)
master-bin.000001 # Query # # use `test`; create table if not exists t2 select * from t1
master-bin.000001 # Query # # use `test`; create temporary table tt1 (a int)
master-bin.000001 # Query # # use `test`; create table if not exists t3 like tt1
master-bin.000001 # Query # # use `mysql`; INSERT INTO user SET host='localhost', user='@#@', password=password('Just a test')
master-bin.000001 # Query # # use `mysql`; UPDATE user SET password=password('Another password') WHERE host='localhost' AND user='@#@'
master-bin.000001 # Query # # use `mysql`; DELETE FROM user WHERE host='localhost' AND user='@#@'
2006-09-28 17:51:27 +02:00
drop table t1,t2,t3,tt1;
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.
2006-07-09 17:52:19 +02:00
create table t1 (a int not null auto_increment, primary key (a)) engine=myisam;
set @@session.auto_increment_increment=1, @@session.auto_increment_offset=1;
insert delayed into t1 values (207);
insert delayed into t1 values (null);
insert delayed into t1 values (300);
2007-03-29 21:38:03 +02:00
show binlog events from <binlog_start>;
2006-09-28 17:42:41 +02:00
Log_name Pos Event_type Server_id End_log_pos Info
2007-03-30 04:44:49 +02:00
master-bin.000001 # Query # # use `test`; create table t1 (id tinyint auto_increment primary key)
master-bin.000001 # Intvar # # INSERT_ID=127
master-bin.000001 # Query # # use `test`; insert into t1 values(null)
master-bin.000001 # Query # # use `test`; drop table t1
master-bin.000001 # Query # # use `test`; create table t1 (a int)
master-bin.000001 # Query # # use `test`; create table if not exists t2 select * from t1
master-bin.000001 # Query # # use `test`; create temporary table tt1 (a int)
master-bin.000001 # Query # # use `test`; create table if not exists t3 like tt1
master-bin.000001 # Query # # use `mysql`; INSERT INTO user SET host='localhost', user='@#@', password=password('Just a test')
master-bin.000001 # Query # # use `mysql`; UPDATE user SET password=password('Another password') WHERE host='localhost' AND user='@#@'
master-bin.000001 # Query # # use `mysql`; DELETE FROM user WHERE host='localhost' AND user='@#@'
master-bin.000001 # Query # # use `test`; drop table t1,t2,t3,tt1
master-bin.000001 # Query # # use `test`; create table t1 (a int not null auto_increment, primary key (a)) engine=myisam
master-bin.000001 # Table_map # # table_id: # (test.t1)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Table_map # # table_id: # (test.t1)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Table_map # # table_id: # (test.t1)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
2006-09-12 15:42:13 +02:00
insert delayed into t1 values (null),(null),(null),(null);
insert delayed into t1 values (null),(null),(400),(null);
2006-09-28 17:42:41 +02:00
11 == 11
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.
2006-07-09 17:52:19 +02:00
select * from t1;
a
207
208
300
2006-09-12 15:42:13 +02:00
301
302
303
304
305
306
400
401
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.
2006-07-09 17:52:19 +02:00
drop table t1;
2007-03-20 09:50:10 +01:00
reset master;
drop table if exists t3;
create table t3 (a int(11) NOT NULL AUTO_INCREMENT, b text, PRIMARY KEY (a) ) engine=innodb;
show master status;
File Position Binlog_Do_DB Binlog_Ignore_DB
2007-03-30 04:44:49 +02:00
master-bin.000001 346
2007-03-20 09:50:10 +01:00
insert into t3(b) values ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');
insert into t3(b) values ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');
insert into t3(b) values ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');
insert into t3(b) values ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');
show master status /* must show new binlog index after rotating */;
File Position Binlog_Do_DB Binlog_Ignore_DB
2007-03-30 04:44:49 +02:00
master-bin.000002 106
2007-03-20 09:50:10 +01:00
drop table t3;
