If a binlog file is manually replaced with a namesake directory the internal purging did
not handle the error of deleting the file so that eventually
a post-execution guards fires an assert.
Fixed with reusing a snippet of code for bug@18199 to tolerate lack of the file but no other error
at an attempt to delete it.
The same applied to the index file deletion.
The cset carries pieces of manual merging.
mysql-test/r/binlog_index.result:
new results
mysql-test/r/ctype_big5.result:
results changed
mysql-test/suite/binlog/r/binlog_auto_increment_bug33029.result:
new results
mysql-test/suite/binlog/r/binlog_stm_blackhole.result:
new results
mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test:
cleanup. still todo: to let the test run multiple times w/o restarting the server (just ./mtr test)
mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result:
results changed
mysql-test/suite/rpl/t/rpl_stm_auto_increment_bug33029.test:
guarding the test with statement format condition as the logics of the test requires
sql/log.cc:
two changes. One for the bug, other manual merge.
The bug change needs MYF(0) to pass to my_delete because not all error out of the function
are critical. The finer check is done on the caller of my_delete similarly how it was implemented
for bug@18199 fixes. Non-existance of a file is not a critical error.
sql/sql_class.cc:
manual merge, removing extra automatically brought hunk.
If a binlog file is manually replaced with a namesake directory the internal purging did
not handle the error of deleting the file so that eventually
a post-execution guards fires an assert.
Fixed with reusing a snippet of code for bug@18199 to tolerate lack of the file but no other error
at an attempt to delete it.
The same applied to the index file deletion.
The cset carries pieces of manual merging.
into mysql1000.(none):/home/andrei/MySQL/MERGE/5.1-main2rpl
client/mysqltest.c:
Auto merged
mysql-test/t/disabled.def:
Auto merged
sql/slave.cc:
Auto merged
sql/slave.h:
Auto merged
sql/sql_class.cc:
Auto merged
into a88-113-38-195.elisa-laajakaista.fi:/home/my/bk/mysql-5.1-marvel
client/mysqldump.c:
Auto merged
client/mysqltest.c:
Auto merged
include/my_global.h:
Auto merged
mysql-test/lib/mtr_report.pl:
Auto merged
sql/ha_partition.cc:
Auto merged
sql/handler.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/log.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/table.cc:
Auto merged
sql/unireg.cc:
Auto merged
storage/myisam/ha_myisam.cc:
Auto merged
storage/myisam/mi_dynrec.c:
Auto merged
storage/myisam/mi_open.c:
Auto merged
storage/myisammrg/ha_myisammrg.cc:
Auto merged
include/config-win.h:
Manual merge between main 5.1 and 5.1 marvel.
mysql-test/r/change_user.result:
Manual merge between main 5.1 and 5.1 marvel.
mysql-test/t/change_user.test:
Manual merge between main 5.1 and 5.1 marvel.
sql/sql_plugin.cc:
Manual merge between main 5.1 and 5.1 marvel.
into rhel5-ia64-a.mysql.com:/data0/tsmith/build/51
sql/mysqld.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_class.cc:
Auto merged
mysql-test/r/drop.result:
SCCS merged
mysql-test/t/drop.test:
SCCS merged
into mail.hezx.com:/media/sda3/work/mysql/bkwork/b33029_5.0_to_5.1_fails_on_dup_key/5.1
sql/slave.cc:
Auto merged
sql/slave.h:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
libmysql/libmysql.c:
Manual merge
sql/sql_class.cc:
Don't send anything back to the client if disabled.
sql/sql_prepare.cc:
Don't send any packet back for statement close.
tests/mysql_client_test.c:
Manual merge
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.1 fixed it to ignore the SET INSERT_ID value when
executing functions/triggers if it is replicating from a master
of buggy versions, another patch for 5.0 fixed it not to generate
the erroneous Intvar event.
mysql-test/include/show_binlog_events.inc:
add $binlog_start parameter to show binlog events from a given position
sql/slave.cc:
Add function to check for bug#33029
sql/slave.h:
Add function to check for bug#33029
sql/sql_class.cc:
if master has bug#33029, reset auto_inc_intervals_forced for sub statements
add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument
sql/sql_class.h:
Add member to save and restore auto_inc_intervals_forced
sql/structs.h:
add copy constructor and assignment operator for Discrete_intervals_list
add a new function Discrete_intervals_list::append that takes a Discrete_interval as argument
mysql-test/std_data/bug33029-slave-relay-bin.000001:
relay logs from a buggy 5.0 master for test case of BUG#33029
mysql-test/suite/binlog/r/binlog_auto_increment_bug33029.result:
Test if the slave can process relay logs from a buggy master of BUG#33029
mysql-test/suite/binlog/t/binlog_auto_increment_bug33029-master.opt:
Test if the slave can process relay logs from a buggy master of BUG#33029
mysql-test/suite/binlog/t/binlog_auto_increment_bug33029.test:
Test if the slave can process relay logs from a buggy master of BUG#33029
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.1 fixed it to ignore the SET INSERT_ID value when
executing functions/triggers if it is replicating from a master
of buggy versions, another patch for 5.0 fixed it not to generate
the erroneous Intvar event.
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.0 fixed it not to generate the erroneous Intvar
event, another patch for 5.1 fixed it to ignore the SET INSERT_ID
value when executing functions/triggers if it is replicating from
a master of buggy versions.
mysql-test/include/show_binlog_events.inc:
add $binlog_start parameter to set the start position when show binlog events, if not set a default value will be used.
mask out column 2(Pos), 4(Server_id), table_id, and file_id
sql/sql_class.cc:
Reset insert_id_used after each query in SP
mysql-test/r/rpl_auto_increment_bug33029.result:
Add test for bug33029, test if the master generate the erroneous event or not
mysql-test/t/rpl_auto_increment_bug33029.test:
Add test for bug33029, test if the master generate the erroneous event or not
using a trig in SP
For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.
Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.
Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement. When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.
The patch for 5.0 fixed it not to generate the erroneous Intvar
event, another patch for 5.1 fixed it to ignore the SET INSERT_ID
value when executing functions/triggers if it is replicating from
a master of buggy versions.
into a88-113-38-195.elisa-laajakaista.fi:/home/my/bk/mysql-5.1-marvel
client/mysqltest.c:
Auto merged
mysql-test/r/change_user.result:
Auto merged
mysql-test/t/change_user.test:
Auto merged
sql/handler.cc:
Auto merged
sql/handler.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/log.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_test.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/table.h:
Auto merged
The DBUG code emits the current value of the proc_info member of THD,
which may be set to NULL. It was wrong to dereference that value
with the format string %s without verifying that it was valid.
Now, insert an inline test that substitutes the string "(null)" for
NULL pointers.
sql/sql_class.cc:
Dereferencing a NULL is illegal (though not fatal for %s on some
platforms), and we have no assurance that the caller didn't call us
with a valid string.
The DBUG code emits the current value of the proc_info member of THD,
which may be set to NULL. It was wrong to dereference that value
with the format string %s without verifying that it was valid.
Now, insert an inline test that substitutes the string "(null)" for
NULL pointers.
into hynda.mysql.fi:/home/my/mysql-5.1-marvel
BitKeeper/etc/ignore:
auto-union
client/mysqldump.c:
Auto merged
client/mysqltest.c:
Auto merged
include/my_global.h:
Auto merged
include/my_sys.h:
Auto merged
sql/handler.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_plugin.cc:
Auto merged
storage/myisam/mi_check.c:
Auto merged
storage/myisam/mi_dynrec.c:
Auto merged
storage/myisam/mi_write.c:
Auto merged
storage/myisam/myisamdef.h:
Auto merged
storage/myisam/myisampack.c:
Auto merged
sql/mysqld.cc:
Manual merge with main 5.1 tree.
into quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged
client/mysqltest.c:
Auto merged
mysql-test/r/view.result:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/ha_ndbcluster_binlog.cc:
Auto merged
sql/handler.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_connect.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
tests/mysql_client_test.c:
Auto merged
mysql-test/suite/rpl_ndb/t/disabled.def:
Manually merged.
mysql-test/t/disabled.def:
Manually merged.
into trift2.:/MySQL/M51/push-5.1
configure.in:
Auto merged
extra/yassl/src/handshake.cpp:
Auto merged
extra/yassl/src/template_instnt.cpp:
Auto merged
extra/yassl/src/yassl_imp.cpp:
Auto merged
mysql-test/mysql-test-run.pl:
Auto merged
sql/ha_ndbcluster_binlog.cc:
Auto merged
sql/handler.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/mysqld.cc:
Auto merged
sql/sql_class.cc:
Auto merged
storage/ndb/src/common/util/OutputStream.cpp:
Auto merged
storage/ndb/src/kernel/blocks/dbtux/DbtuxScan.cpp:
Auto merged
storage/ndb/tools/waiter.cpp:
Auto merged
Fixes the following bugs:
- Bug #33349: possible race condition revolving around data dictionary and repartitioning
Introduce retry/sleep logic as a workaround for a transient bug
where ::open fails for partitioned tables randomly if we are using
one file per table.
- Bug #34053: normal users can enable innodb_monitor logging
In CREATE TABLE and DROP TABLE check whether the table in question is one
of the magic innodb_monitor tables and whether the user has enough rights
to mess with it before doing anything else.
- Bug #22868: 'Thread thrashing' with > 50 concurrent conns under an upd-intensive workloadw
- Bug #29560: InnoDB >= 5.0.30 hangs on adaptive hash rw-lock 'waiting for an X-lock'
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
- Bug #30930: Add auxiliary function to retrieve THD::thread_id
Add thd_get_thread_id() function. Also make check_global_access() function
visible to InnoDB under INNODB_COMPATIBILITY_HOOKS #define.
include/mysql/plugin.h:
Add thd_get_thread_id() accessor function
mysql-test/r/innodb.result:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2261:
branches/5.1: Merge a change from MySQL AB:
ChangeSet@2007-10-13 15:49:42+03:00, aelkin@koti.dsl.inet.fi
Bug #29136 erred multi-delete on trans table does not rollback the statement
innodb.test, innodb.result: trans table specific test added
mysql-test/t/innodb.test:
Applied InnoDB snapshot innodb-5.1-ss2298
sql/mysql_priv.h:
Make check_global_access() declaration available if when
INNODB_COMPATIBILITY_HOOKS is defined.
sql/sql_class.cc:
Add thd_get_thread_id() accessor function.
Add 'extern "C"' to definition for thd_get_xid(). Not strictly
needed, but in keeping with our coding style.
storage/innobase/btr/btr0cur.c:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2295:
branches/5.1:
Merge r2294 from branches/5.0:
Fix typo and add comma in comment.
storage/innobase/handler/ha_innodb.cc:
Applied InnoDB snapshot innodb-5.1-ss2298
- But remove the declaration of check_global_access() from ha_innodb.cc,
because it is now visible in mysql_priv.h under INNODB_COMPATIBILITY_HOOKS
Revision r2270:
branches/5.1:
Rename the user visible parameter innodb-use-adaptive-hash-indexes to
innodb-adaptive-hash-index so that it is in sync with MySQL 5.0.
Suggested by: Heikki
Approved by: Heikki
Revision r2236:
branches/5.1: bug#33349
Introduce retry/sleep logic as a workaround for a transient bug
where ::open fails for partitioned tables randomly if we are using
one file per table.
Reviewed by: Heikki
Revision r2282:
branches/5.1:
Fix Bug#34053:
* In CREATE TABLE and DROP TABLE check whether the table in question is one
of the magic innodb_monitor tables and whether the user has enough rights
to mess with it before doing anything else.
* Implement a mysql-test testcase.
Approved by: Heikki
Revision r2246:
branches/5.1:
Fix formatting of the autoinc-lock-mode command line parameter.
Old view (./mysqld --help --verbose):
--innodb-autoinc-lock-mode=#
The AUTOINC lock modes supported by InnoDB:
0 => Old
style AUTOINC locking (for backward compatibility)
1 =>
New style AUTOINC locking
2 => No AUTOINC locking
(unsafe for SBR)
New view:
--innodb-autoinc-lock-mode=#
The AUTOINC lock modes supported by InnoDB:
0 => Old style AUTOINC locking (for backward
compatibility)
1 => New style AUTOINC locking
2 => No AUTOINC locking (unsafe for SBR)
Looks like these strings are "automatically" wrapped by MySQL in the
following way:
* newlines (\n) in the string are ignored
* newline separator (\n) is inserted every 57 or so characters.
* lots of white space is appended to each inserted new line.
Approved by: Heikki
storage/innobase/include/os0sync.h:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/include/read0read.h:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2188:
branches/5.1: Remove unused field can_be_too_old from read_view_struct.
storage/innobase/include/row0mysql.h:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2282:
branches/5.1:
Fix Bug#34053:
* In CREATE TABLE and DROP TABLE check whether the table in question is one
of the magic innodb_monitor tables and whether the user has enough rights
to mess with it before doing anything else.
* Implement a mysql-test testcase.
Approved by: Heikki
Revision r2272:
branches/5.1:
Fix typo in comment.
storage/innobase/include/sync0arr.h:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/include/sync0rw.h:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/include/sync0rw.ic:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/include/sync0sync.h:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/include/sync0sync.ic:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/os/os0sync.c:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/read/read0read.c:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2188:
branches/5.1: Remove unused field can_be_too_old from read_view_struct.
storage/innobase/row/row0mysql.c:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2282:
branches/5.1:
Fix Bug#34053:
* In CREATE TABLE and DROP TABLE check whether the table in question is one
of the magic innodb_monitor tables and whether the user has enough rights
to mess with it before doing anything else.
* Implement a mysql-test testcase.
Approved by: Heikki
Revision r2272:
branches/5.1:
Fix typo in comment.
storage/innobase/srv/srv0srv.c:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/sync/sync0arr.c:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/sync/sync0rw.c:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
storage/innobase/sync/sync0sync.c:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2268:
branches/5.1: Port of r2267
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
Reviewed by: Heikki
mysql-test/r/innodb_bug34053.result:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2282:
branches/5.1:
Fix Bug#34053:
* In CREATE TABLE and DROP TABLE check whether the table in question is one
of the magic innodb_monitor tables and whether the user has enough rights
to mess with it before doing anything else.
* Implement a mysql-test testcase.
Approved by: Heikki
mysql-test/t/innodb_bug34053.test:
Applied InnoDB snapshot innodb-5.1-ss2298
Revision r2282:
branches/5.1:
Fix Bug#34053:
* In CREATE TABLE and DROP TABLE check whether the table in question is one
of the magic innodb_monitor tables and whether the user has enough rights
to mess with it before doing anything else.
* Implement a mysql-test testcase.
Approved by: Heikki
Fixes the following bugs:
- Bug #33349: possible race condition revolving around data dictionary and repartitioning
Introduce retry/sleep logic as a workaround for a transient bug
where ::open fails for partitioned tables randomly if we are using
one file per table.
- Bug #34053: normal users can enable innodb_monitor logging
In CREATE TABLE and DROP TABLE check whether the table in question is one
of the magic innodb_monitor tables and whether the user has enough rights
to mess with it before doing anything else.
- Bug #22868: 'Thread thrashing' with > 50 concurrent conns under an upd-intensive workloadw
- Bug #29560: InnoDB >= 5.0.30 hangs on adaptive hash rw-lock 'waiting for an X-lock'
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
- Bug #30930: Add auxiliary function to retrieve THD::thread_id
Add thd_get_thread_id() function. Also make check_global_access() function
visible to InnoDB under INNODB_COMPATIBILITY_HOOKS #define.
into dipika.(none):/opt/local/work/mysql-5.1-2pc-opt-merge-push
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
Auto merged
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
Auto merged
sql/ha_ndbcluster_binlog.cc:
Auto merged
sql/log.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/sp.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_table.cc:
Auto merged
mysql-test/suite/rpl_ndb/t/disabled.def:
Manual merge.
a SELECT doesn't cause ROLLBACK of statem".
The idea of the fix is to ensure that we always commit the current
statement at the end of dispatch_command(). In order to not issue
redundant disc syncs, an optimization of the two-phase commit
protocol is implemented to bypass the two phase commit if
the transaction is read-only.
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
Update test results.
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
Update test results.
mysql-test/suite/rpl_ndb/t/disabled.def:
Disable the tests, for which this changeset reveals a bug:
the injector thread does not always add 'statement commit' to the
rows injected in circular replication set up.
To be investigated separately.
sql/ha_ndbcluster_binlog.cc:
Add close_thread_tables() to run_query: this ensures
that all tables are closed and there is no pending statement transaction.
sql/handler.cc:
Implement optimisation of read-only transactions.
If a transaction consists only of DML statements that do not change
data, we do not perform a two-phase commit for it
(run one phase commit only).
sql/handler.h:
Implement optimisation of read-only transactions.
If a transaction consists only of DML statements that do not change
data, we do not perform a two-phase commit for it
(run one phase commit only).
sql/log.cc:
Mark the binlog transaction read-write whenever it's started.
We never read from binlog, so it's safe and least intrusive to add
this mark up here.
sql/log_event.cc:
Update to the new layout of thd->transaction.
sql/rpl_injector.cc:
Always commit statement transaction before committing the global one.
sql/sp.cc:
Ad comments.
sql/sp_head.cc:
Add comments.
sql/sql_base.cc:
Commit transaction at the end of the statement. Always.
sql/sql_class.cc:
Update thd_ha_data to return the right pointer in the new layout.
Fix select_dumpvar::send_data to properly return operation status.
A test case from commit.inc would lead to an assertion failure in the
diagnostics area (double assignment). Not test otherwise by the test suite.
sql/sql_class.h:
Implement a new layout of storage engine transaction info in which
it is easy to access all members related to the handlerton only
based on ht->slot.
sql/sql_cursor.cc:
Update to the new layout of thd->transaction.
sql/sql_delete.cc:
Remove wrong and now redundant calls to ha_autocommit_or_rollback.
The transaction is committed in one place, at the end of the statement.
Remove calls to mysql_unlock_tables, since some engines count locks
and commit statement transaction in unlock_tables(), which essentially
equates mysql_unlock_tables to ha_autocommit_or_rollback.
Previously it was necessary to unlock tables soon because we wanted
to avoid sending of 'ok' packet to the client under locked tables.
This is no longer necessary, since OK packet is also sent from one place
at the end of transaction.
sql/sql_do.cc:
Add DO always clears the error, we must rollback the current
statement before this happens. Otherwise the statement will be committed,
and not rolled back in the end.
sql/sql_insert.cc:
Remove wrong and now redundant calls to ha_autocommit_or_rollback.
The transaction is committed in one place, at the end of the statement.
Remove calls to mysql_unlock_tables, since some engines count locks
and commit statement transaction in unlock_tables(), which essentially
equates mysql_unlock_tables to ha_autocommit_or_rollback.
Previously it was necessary to unlock tables soon because we wanted
to avoid sending of 'ok' packet to the client under locked tables.
This is no longer necessary, since OK packet is also sent from one place
at the end of transaction.
sql/sql_load.cc:
Remove wrong and now redundant calls to ha_autocommit_or_rollback.
The transaction is committed in one place, at the end of the statement.
Remove calls to mysql_unlock_tables, since some engines count locks
and commit statement transaction in unlock_tables(), which essentially
equates mysql_unlock_tables to ha_autocommit_or_rollback.
Previously it was necessary to unlock tables soon because we wanted
to avoid sending of 'ok' packet to the client under locked tables.
This is no longer necessary, since OK packet is also sent from one place
at the end of transaction.
sql/sql_parse.cc:
Implement optimisation of read-only transactions: bypass 2-phase
commit for them.
Always commit statement transaction before commiting the global one.
Fix an unrelated crash in check_table_access, when called from
information_schema.
sql/sql_partition.cc:
Partitions commit at the end of a DDL operation.
Make sure that send_ok() is done only if the commit has succeeded.
sql/sql_table.cc:
Use ha_autocommit_or_rollback and end_active_trans everywhere.
Add end_trans to mysql_admin_table, so that it leaves no pending
transaction.
sql/sql_udf.cc:
Remvove a redundant call to close_thread_tables()
sql/sql_update.cc:
Remove wrong and now redundant calls to ha_autocommit_or_rollback.
The transaction is committed in one place, at the end of the statement.
Remove calls to mysql_unlock_tables, since some engines count locks
and commit statement transaction in unlock_tables(), which essentially
equates mysql_unlock_tables to ha_autocommit_or_rollback.
Previously it was necessary to unlock tables soon because we wanted
to avoid sending of 'ok' packet to the client under locked tables.
This is no longer necessary, since OK packet is also sent from one place
at the end of transaction.
mysql-test/include/commit.inc:
New BitKeeper file ``mysql-test/include/commit.inc''
mysql-test/r/commit_1innodb.result:
New BitKeeper file ``mysql-test/r/commit_1innodb.result''
mysql-test/t/commit_1innodb.test:
New BitKeeper file ``mysql-test/t/commit_1innodb.test''
a SELECT doesn't cause ROLLBACK of statem".
The idea of the fix is to ensure that we always commit the current
statement at the end of dispatch_command(). In order to not issue
redundant disc syncs, an optimization of the two-phase commit
protocol is implemented to bypass the two phase commit if
the transaction is read-only.
into quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged
client/mysqlbinlog.cc:
Auto merged
sql/slave.cc:
Auto merged
sql/slave.h:
Auto merged
sql/sql_class.cc:
Auto merged
into hynda.mysql.fi:/home/my/mysql-5.1-marvel
sql/mysqld.cc:
Auto merged
sql/sql_class.cc:
Auto merged
include/my_base.h:
Manual merge between main 5.1 and team tree.
Added IMPOSSIBLE_RESULT to avoid compiler warnings when using (Item_result) -1 as a dummy value
Changed PAGE_SIZE to TEST_PAGE_SIZE to avoid compiler errors on systems where PAGE_SIZE is defined
client/get_password.c:
Fixed compiler warning
cmd-line-utils/readline/bind.c:
Fixed compiler warning
cmd-line-utils/readline/chardefs.h:
Fixed compiler warning by adding marco to be used when largest_char is 255
cmd-line-utils/readline/display.c:
Fixed compiler warnings by removing not accessed variables
cmd-line-utils/readline/histexpand.c:
Fixed compiler warnings by removing not accessed variables
cmd-line-utils/readline/history.c:
Fixed compiler warnings by adding cast
cmd-line-utils/readline/text.c:
Fixed compiler warnings by removing not accessed variables and adding casts
dbug/dbug.c:
Fixed compiler warnings by changing types
include/mysql_com.h:
Added IMPOSSIBLE_RESULT to avoid compiler warnings when using (Item_result) -1 as a dummy value
libmysql/libmysql.c:
Fixed compiler warning
mysql-test/t/query_cache_debug.test:
Mark test as BIG as it uses a lot of memory
mysys/mf_iocache2.c:
Fixed compiler warnings by adding cast
sql/event_data_objects.cc:
Fixed compiler warnings by removing not used code
sql/events.cc:
Fixed compiler warnings by removing not used code
sql/field.cc:
Fixed compiler warnings by adding cast and removed not accessed variables
sql/ha_partition.cc:
Fixed compiler warnings by removing not used code
sql/item.cc:
Fixed compiler warnings by removing not accessed variables
Use IMPOSSIBLE_RESULT instead of (Item_result)-1
sql/item_cmpfunc.cc:
Fixed compiler warnings by removing not accessed variables
sql/item_func.cc:
Fixed compiler warnings by removing not used code and not accessed variables
Added IMPOSSIBLE_RESULT
sql/item_subselect.cc:
Fixed compiler warnings by removing not accessed variables
sql/item_xmlfunc.cc:
Fixed forgotten setting of xpath->error
sql/log.cc:
Fixed compiler warnings by removing not accessed variables
sql/log_event.cc:
Added IMPOSSIBLE_RESULT into switch
Fixed wrong usage of DBUG_ASSERT(1)
Removed always true DBUG_ASSERT()
sql/mysqld.cc:
Fixed compiler warnings by adding casts for ULONG_MAX
sql/opt_sum.cc:
Fixed compiler warnings by removing not used code
Removed wrong DBUG_ASSERT()
sql/partition_info.cc:
Fixed compiler warnings by removing not accessed variables
sql/rpl_injector.h:
Removed always true part from DBUG_ASSERT() to remove compiler warning
sql/spatial.cc:
Fixed compiler warnings by removing not accessed variables
sql/sql_acl.cc:
Fixed compiler warnings by removing not accessed variables
sql/sql_base.cc:
Fixed compiler warnings by removing not accessed variables
sql/sql_cache.cc:
Fixed compiler warnings by removing not accessed variables
sql/sql_class.cc:
Fixed compiler warnings by:
- Removing always true part from DBUG_ASSERT()
- Removing not used code
- Added IMPOSSIBLE_RESULT into switch
sql/sql_load.cc:
Fixed compiler warnings by removing not accessed variables
sql/sql_parse.cc:
Fixed compiler warnings by:
- Removing not accessed variables
- Removing always true part from DBUG_ASSERT()
- Removing not used code
sql/sql_plugin.cc:
Added comment
sql/sql_prepare.cc:
Fixed compiler warnings by removing not accessed variables
sql/sql_show.cc:
Fixed compiler warnings by using correct cast
sql/sql_table.cc:
Fixed compiler warnings by removing not used code and removing not accessed variables
sql/table.cc:
Fixed compiler warnings by removing not accessed variables
sql/time.cc:
Fixed wrong DBUG_ASSERT(1)
storage/maria/unittest/Makefile.am:
Changed PAGE_SIZE to TEST_PAGE_SIZE to avoid compiler errors on systems where PAGE_SIZE is defined
storage/maria/unittest/ma_pagecache_consist.c:
Changed PAGE_SIZE to TEST_PAGE_SIZE to avoid compiler errors on systems where PAGE_SIZE is defined
storage/maria/unittest/ma_pagecache_single.c:
Changed PAGE_SIZE to TEST_PAGE_SIZE to avoid compiler errors on systems where PAGE_SIZE is defined
tests/mysql_client_test.c:
Fixed compiler warnings by removing not accessed variables and changing types
behave randomly with mysql_change_user.
The problem was that global status variables were not updated
in THD::check_user(), so thread statistics were lost after
COM_CHANGE_USER.
The fix is to update global status variables with the thread ones
before preparing the thread for new user.
mysql-test/r/change_user.result:
Update result file.
mysql-test/t/change_user.test:
Add a test case for Bug#31222: com_% global status counters
behave randomly with mysql_change_user.
sql/sql_class.cc:
Update global status variables when we're handling
COM_CHANGE_USER for a thread.
behave randomly with mysql_change_user.
The problem was that global status variables were not updated
in THD::check_user(), so thread statistics were lost after
COM_CHANGE_USER.
The fix is to update global status variables with the thread ones
before preparing the thread for new user.
tree with main.
sql/sql_binlog.cc:
Adding code to free memory after execution of BINLOG statement.
It caused a memory leak in the case that the execution failed
for any reason.
sql/sql_class.cc:
Since rli_fake is checked for NULL at various occations to mean
that no rli_fake is assigned, NULL is assigned to rli_fake after
deleting the instance.
