List:Internals« Previous MessageNext Message »
From:sasha Date:July 18 2001 8:26pm
Subject:bk commit into 3.23 tree
View as plain text  
Below is the list of changes that have just been commited into a local
3.23. repository of sasha. When sasha does a push, they will be
propogaged to the main repository and within 24 hours after the push into
the public repository. For information on how to access
the public repository see

ChangeSet@stripped, 2001-07-18 14:26:43-06:00, sasha@stripped
  fixed mysterious offset confusion bug
  added a test case for it - took some creative work to figure out
  how to make it happen at will
  updated the manual

    1.1 01/07/18 14:26:43 sasha@stripped +4 -0

    1.1 01/07/18 14:26:43 sasha@stripped +43 -0

    1.0 01/07/18 14:26:43 sasha@stripped +0 -0
    BitKeeper file /home/sasha/src/bk/mysql/mysql-test/r/rpl_mystery22.result

    1.0 01/07/18 14:26:43 sasha@stripped +0 -0
    BitKeeper file /home/sasha/src/bk/mysql/mysql-test/t/rpl_mystery22.test

    1.3 01/07/18 14:26:43 sasha@stripped +9 -2
    tried hard to get slave confused, but failed. nevertheless, a more
    exhaustive test case does not hurt

    1.110 01/07/18 14:26:43 sasha@stripped +2 -0
    fixed mysterious offset confusion bug

    1.637 01/07/18 14:26:42 sasha@stripped +10 -4
    fixed wrong info on SLAVE_SKIP_COUNTER
    fixed wrong info in BitKeeper tree build instructions
    updated change history about bug fix

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	sasha
# Host:
# Root:	/home/sasha/src/bk/mysql

--- 1.636/Docs/manual.texi	Wed Jul 18 02:31:17 2001
+++ 1.637/Docs/manual.texi	Wed Jul 18 14:26:42 2001
@@ -6543,8 +6543,8 @@
 A collection of our standard configure scripts is located in the
 @file{BUILD/} subdirectory.  If you are lazy, you can use
-@file{BUILD/compile-pentium-debug}.  It will actually work on a lot of
-non-x86 machines despite its name.
+@file{BUILD/compile-pentium-debug}. To compile on a different architecture,
+modify the script removing flags that are Pentium-specific.
 When the build is done, run @code{make install}.  Be careful with this
@@ -29828,8 +29828,11 @@
 If you have decided you can skip the next query, do
 @code{SET SQL_SLAVE_SKIP_COUNTER=1; SLAVE START;} to skip a query that
-does not use auto_increment, last_insert_id or timestamp, or
+does not use auto_increment, or last_insert_id  or
+@code{SET SQL_SLAVE_SKIP_COUNTER=2; SLAVE START;} otherwise. The reason
+auto_increment/last_insert_id queries are different is that they take
+two events in the binary log of the master.
 If you are sure the slave started out perfectly in sync with the master,
 and no one has updated  the tables involved outside of slave thread,
@@ -45727,6 +45730,9 @@
 @node News-3.23.40, News-3.23.39, News-3.23.x, News-3.23.x
 @appendixsubsec Changes in release 3.23.40
 @itemize @bullet
+Fixed bug in slave thread when under some rare circumstances it could
+get 22 bytes ahead on the offset in the master
 Added @code{slave_wait_timeout} for replication.

--- 1.109/sql/	Tue Jul 17 14:22:39 2001
+++ 1.110/sql/	Wed Jul 18 14:26:43 2001
@@ -1222,6 +1222,8 @@
   thd->thread_stack = (char*)&thd; // remember where our stack is
   thd->temporary_tables = save_temporary_tables; // restore temp tables
+  glob_mi.pending = 0;  //this should always be set to 0 when the slave thread
+  // is started
   DBUG_PRINT("info",("master info: log_file_name=%s, position=%s",
 		     glob_mi.log_file_name, llstr(glob_mi.pos,llbuff)));
--- New file ---
+++ mysql-test/r/rpl_mystery22.result	01/07/18 14:26:43

--- New file ---
+++ mysql-test/t/rpl_mystery22.test	01/07/18 14:26:43
# test case to make slave thread get ahead by 22 bytes

source include/;
connection master;
# first, cause a duplicate key problem on the slave
create table t1(n int auto_increment primary key);
connection slave;
insert into t1 values (2);
connection master;
insert into t1 values(NULL);
insert into t1 values(NULL);
connection slave;
sleep 1; # there is no way around this sleep - we have to wait until
# the slave tries to run the query, fails and aborts slave thread
delete from t1 where n = 2;
slave start;
#now the buggy slave would be confused on the offset but it can replicate
#in order to make it break, we need to stop/start the slave one more time
slave stop;
connection master;
# to be able to really confuse the slave, we need some non-auto-increment
# events in the log
create table t2(n int);
drop table t2;
insert into t1 values(NULL);
connection slave;
slave start;
#now the truth comes out - if the slave is buggy, it will never sync because
#the slave thread is not able to read events
select * from t1;
#clean up
connection master;
drop table t1;
connection slave;

--- 1.2/mysql-test/t/rpl_sporadic_master.test	Mon Jul 16 04:27:27 2001
+++ 1.3/mysql-test/t/rpl_sporadic_master.test	Wed Jul 18 14:26:43 2001
@@ -3,12 +3,19 @@
 source include/;
 connection master;
-drop table if exists t1;
+drop table if exists t1,t2;
+create table t2(n int);
 create table t1(n int not null auto_increment primary key);
 insert into t1 values (NULL),(NULL);
 delete from t1;
 # We have to use 4 in the following to make this test work with all table types
 insert into t1 values (4),(NULL);
+connection slave;
+slave stop;
+slave start;
+connection master;
 insert into t1 values (NULL),(NULL);
 flush logs;
 delete from t1;
@@ -20,7 +27,7 @@
 select * from t1;
 connection master;
-drop table t1;
+drop table t1,t2;
 connection slave;
bk commit into 3.23 treesasha18 Jul