correctly - crashes server !
Creating federated table with connect string containing empty
(zero-length) host name and port is evaluated as 0 (port is
incorrect, omitted or 0) crashes server.
This happens because federated calls strcmp() with NULL pointer.
Fixed by avoiding strcmp() call if hostname is set to NULL.
mysql-test/r/federated.result:
A test case for BUG#34788.
mysql-test/t/federated.test:
A test case for BUG#34788.
sql/ha_federated.cc:
Fixed that parse_url() may call strcmp() with NULL pointer.
A big test was written and is committed, which found 3 bugs in total:
- ALTER TABLE PAGE_CHECKSUM=0 sometimes had no effect
- ALTER TABLE ENGINE=MARIA sometimes changed page checksumming in
the table
- SHOW CREATE TABLE and 'maria_chk -dv' disagreed on the presence
of page checksumming.
They are all fixed here. Side-effect is that SHOW CREATE TABLE now
always prints a PAGE_CHECKSUM clause for Maria tables.
mysql-test/mysql-test-run.pl:
allow calling maria_chk and maria_pack in tests
mysql-test/r/maria.result:
PAGE_CHECKSUM=0 is now always printed
mysql-test/t/create.test:
PAGE_CHECKSUM= is now always present in SHOW CREATE TABLE of Maria tables
mysql-test/t/disabled.def:
better bug number
sql/sql_table.cc:
If ALTER TABLE PAGE_CHECKSUM=#, it affects the engine's data (structure
of data pages) so a full table rebuild is needed. We already did
so for ROW_FORMAT=#, following same logic. This fixes disagreements
between SHOW CREATE TABLE and 'maria_chk -dv' regarding the
presence of page checksums after certain ALTER TABLE (as seen
with the attached testcase).
storage/maria/ha_maria.cc:
In ALTER TABLE PAGE_CHECKSUM=0, ha_maria::update_create_info() started
with create_info->page_checksum=HA_CHOICE_NO and wrongly set it
to the table's original setting, which is HA_CHOICE_YES if the table
had page checksums, in which case the ALTER left page checksum
in the table.
The fix for this bug is: only if create_info->page_checksum is
undefined (no clause in the ALTER TABLE, or we are in SHOW CREATE TABLE)
we may set HA_CHOICE_YES.
The second bug in this file was that the code left HA_CHOICE_UNDEF if
the table didn't have page checksums originally, leading ALTER TABLE
ENGINE=MARIA to change the table's page checksum to the value of
maria_page_checksum.
This is fixed by setting create_info->page_checksum to HA_CHOICE_NO
if UNDEF and table does not have page checksum.
The side-effect of this last fix, because ha_maria::update_create_info()
is also called by SHOW CREATE TABLE, is that:
SET GLOBAL maria_page_checksum=0;
CREATE TABLE t(a INT) ENGINE=MARIA;
SHOW CREATE TABLE t;
which used to not show a PAGE_CHECKSUM= clause, now shows PAGE_CHECKSUM=0.
I consider this side-effect good:
- clearer for users: it eliminates the differences between the
above and this:
SET GLOBAL maria_page_checksum=0;
CREATE TABLE t(a INT) ENGINE=MARIA PAGE_CHECKSUM=0;
SHOW CREATE TABLE t;
which already showed PAGE_CHECKSUM=0; difference which is not easy
to explain.
- if using mysqldump to copy from one server to another, it eliminates
the dependency on the value of maria_page_checksum being the same on
original server and new server.
mysql-test/r/maria-page-checksum.result:
Result. If you undo the code fixes and run the test, the new result
file will show bugs at:
error lineno 56 : expected PAGE_CHECKSUM=1, got Page checksums are not used
error lineno 73 : expected PAGE_CHECKSUM=0, got ) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1
error lineno 110 : expected PAGE_CHECKSUM=1, got Page checksums are not used
error lineno 164 : expected PAGE_CHECKSUM=1, got Page checksums are not used
error lineno 181 : expected PAGE_CHECKSUM=0, got ) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1
error lineno 218 : expected PAGE_CHECKSUM=1, got Page checksums are not used
error lineno 253 : expected PAGE_CHECKSUM=0, got ) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1
error lineno 307 : expected PAGE_CHECKSUM=0, got ) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1
error lineno 361 : expected PAGE_CHECKSUM=0, got ) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1
error lineno 415 : expected PAGE_CHECKSUM=0, got ) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1
error lineno 488 : expected PAGE_CHECKSUM=1, got Page checksums are not used
error lineno 505 : expected PAGE_CHECKSUM=0, got ) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1
error lineno 542 : expected PAGE_CHECKSUM=1, got Page checksums are not used
error lineno 577 : expected PAGE_CHECKSUM=0, got ) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1
error lineno 631 : expected PAGE_CHECKSUM=0, got ) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1
(lineno is line number in the result file)
mysql-test/t/maria-page-checksum.test:
Test for the 3 bugs
into stella.local:/home2/mydev/mysql-5.1-axmrg
mysql-test/r/partition_not_windows.result:
Auto merged
mysql-test/r/partition_symlink.result:
Auto merged
mysql-test/r/symlink.result:
Auto merged
mysql-test/suite/parts/r/partition_basic_innodb.result:
Auto merged
mysql-test/suite/parts/r/partition_basic_myisam.result:
Auto merged
sql/log_event.cc:
Auto merged
sql/partition_info.cc:
Auto merged
sql/repl_failsafe.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
mysql-test/t/partition_symlink.test:
Manual merge
mysql-test/t/symlink.test:
Manual merge
sql/sql_parse.cc:
Manual merge
When CREATE SERVER is issued, it allocates memory on memory root
to store cached server structure. When DROP SERVER is issued,
it doesn't release this memory, as it is impossible with the
memory root.
We use the same allocation strategy for plugins and acl. The problem
here that there was no way (except for the server restart) to force
'servers' code to release this memory.
With this fix it is possible to release unused server cache memory
by FLUSH PRIVILEGES.
No test case for this fix.
sql/sql_parse.cc:
Reload servers table on FLUSH PRIVILEGES.
sql/sql_servers.cc:
Instead of just marking memory blocks as unused, release memory
used by servers cache and initialize new memory root.
This is needed for FLUSH PRIVILEGES to release unused memory
blocks.
well enough
CREATE SERVER may cause server crash if there is not enough memory
to execute this operation.
Fixed that create_server() and prepare_server_struct_for_insert()
didn't check return value of functions that allocate memory.
As this is out of memory issue fix, not test case available.
sql/sql_servers.cc:
Fixed that create_server() and prepare_server_struct_for_insert()
didn't check return value of functions that allocate memory.
into host.loc:/home/uchum/work/5.1-opt
mysql-test/r/subselect3.result:
Auto merged
mysql-test/t/subselect3.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_subselect.cc:
Auto merged
binlogging of insert into a autoincrement blackhole table ignored
an explicit set insert_id.
Fixed with refining of the blackhole's insert method to call
update_auto_increment() that prepares binlogging the insert query
with the preceeding set insert_id.
Note, as the engine does not store any actual data one has to explicitly
provide to the server with the value of the autoincrement column via
set insert_id. Otherwise binlogging will happend with the default
set insert_id=1.
mysql-test/r/blackhole.result:
results changed
mysql-test/t/blackhole.test:
a regression test for the bug added
sql/ha_blackhole.cc:
blackhole's insert method is refined to call update_auto_increment()
that prepares binlogging the insert query with the preceeding set insert_id.
When swapping out heap I_S tables to disk, this is done after plan refinement.
Thus, READ_RECORD::file will still point to the (deleted) heap handler at start
of execution. This causes segmentation fault if join buffering is used and the
query is a star query where the result is found to be empty before accessing
some table. In this case that table has not been initialized (i.e. had its
READ_RECORD re-initialized) before the cleanup routine tries to close the handler.
Fixed by updating READ_RECORD::file when changing handler.
mysql-test/r/information_schema.result:
Bug#34529: Test result.
mysql-test/t/information_schema.test:
Bug#34529: Test case.
sql/sql_show.cc:
Bug#34529: The fix.
into kaamos.(none):/data/src/opt/bug34512/my51
mysql-test/r/func_group.result:
Auto merged
mysql-test/t/func_group.test:
Auto merged
sql/item_sum.cc:
Auto merged
binlog_format=mixed
Statement-based replication of DELETE ... LIMIT, UPDATE ... LIMIT,
INSERT ... SELECT ... LIMIT is not safe as order of rows is not
defined.
With this fix, we issue a warning that this statement is not safe to
replicate in statement mode, or go to row-based mode in mixed mode.
Note that we may consider a statement as safe if ORDER BY primary_key
is present. However it may confuse users to see very similiar statements
replicated differently.
Note 2: regular UPDATE statement (w/o LIMIT) is unsafe as well, but
this patch doesn't address this issue. See comment from Kristian
posted 18 Mar 10:55.
mysql-test/suite/binlog/r/binlog_stm_ps.result:
Updated a test case according to fix for BUG#34768:
INSERT ... SELECT ... LIMIT is now replicated in row mode.
mysql-test/suite/binlog/r/binlog_unsafe.result:
A test case for BUG#34768.
mysql-test/suite/binlog/t/binlog_unsafe.test:
A test case for BUG#34768.
sql/sql_delete.cc:
Statement-based replication of DELETE ... LIMIT is not safe as order of
rows is not defined, so in mixed mode we go to row-based.
sql/sql_insert.cc:
Statement-based replication of INSERT ... SELECT ... LIMIT is not safe
as order of rows is not defined, so in mixed mode we go to row-based.
sql/sql_update.cc:
Statement-based replication of UPDATE ... LIMIT is not safe as order of
rows is not defined, so in mixed mode we go to row-based.
into mysql.com:/home/svoj/devel/mysql/cov/mysql-5.1-engines
sql/log_event.cc:
Auto merged
sql/repl_failsafe.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
into quad.opbmk:/mnt/raid/alik/MySQL/devel/5.0-rt-merged
libmysql/libmysql.c:
Auto merged
sql-common/client.c:
Auto merged
tests/mysql_client_test.c:
Manually merged.
into quad.opbmk:/mnt/raid/alik/MySQL/devel/5.1-rt-merged
libmysql/libmysql.c:
Auto merged
sql-common/client.c:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
tests/mysql_client_test.c:
Auto merged
Each time the server reloads privileges containing table grants, the
system will allocate too much memory than needed because of badly
chosen growth prediction in the underlying dynamic arrays.
This patch introduces a new signature to the hash container initializer
which enables a much more pessimistic approach in favour for more
efficient memory useage.
This patch was supplied by Google Inc.
include/hash.h:
* New signature for _hash_init.
* Defined new function hash_init2 which takes growth_size argument.
mysys/hash.c:
* New signature for _hash_init.
sql/sql_acl.cc:
* Changed hash_init signature so that it takes a 'growth_size' smaller
than the default. Each time a GRANT_TABLE is allocated a pre-allocated
dynamic array is instantiated. A large growth size can result in too
many unused hash-entries per table-entry and thus be a waste of free
memory.
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
Bug #18453 Warning/error message if there is a mismatch between ...
There were three problems:
1. the reported lack of warnings for the BEFORE syntax of PURGE;
2. the similar lack of warnings for the TO syntax;
3. incompatible behaviour between the two in that the latter blanked out
regardlessly of presence or lack the actual file corresponding to
an index record; the former version gave up at the first mismatch.
fixed with deploying the warning's generation and synronizing logics of
purge_logs() and purge_logs_before_date().
my_stat() is called in either of two branches of purge_logs() (responsible
for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax.
If there is no actual binlog file, my_stat returns NULL and my_delete is
not invoked.
A critical error is reported to the user if a file from the index
could not be retrieved info about or deleted with a system error code
different than ENOENT.
sql/log.cc:
generating warning in two functions.
refining logics to call my_stat() by purge_logs() as it happens
in purge_logs_before_date().
my_delete() is called only if my_stat() ensured existance of the file.
A critical error is reported to the user if a file from the index
could not be my_stat():ed or my_delete():d with an error different
than ENOENT.
sql/share/errmsg.txt:
new error message
mysql-test/include/show_binary_logs.inc:
a new macro - shortcut of show binary logs
mysql-test/r/binlog_index.result:
new results
mysql-test/t/binlog_index.test:
a regression test for the bugs
Updated the test due to bug 32167
Corrected spelling of error message
mysql-test/r/partition_not_windows.result:
Updated test result due to test case changes and corrected spelling error
mysql-test/r/partition_symlink.result:
Bug#35305: partition_symlink test failure
Updated test result due to test case changes
mysql-test/r/symlink.result:
Updated test result due to test case changes and corrected spelling error
mysql-test/t/disabled.def:
Bug#35305: partition_symlink test failure
Enable the test after it has been fixed
mysql-test/t/partition_not_windows.test:
Removed disable/enable_query_log for better result files
mysql-test/t/partition_symlink.test:
Bug#35305: partition_symlink test failure
Changes due to bug 32167
mysql-test/t/symlink.test:
using replace_result instead of disable_query_log
sql/partition_info.cc:
corrected spelling
sql/sql_parse.cc:
corrected spelling
into -engines tree.
hander::table_share was not updated after changing table->s.
sql/ha_partition.cc:
Valgrind warning after merge -main -> -engines, after bug#32943
change_table_ptr can happen in a middle of
alter table rename/drop/... partition
the newly created partitions must get the updated table_share too.
sql/sql_base.cc:
Bug#32943 was missing a call to change_table_ptr, this was found by valgrind
after a merge from -main to -engines.
The problem was that the COM_STMT_SEND_LONG_DATA was sending a response
packet if the prepared statement wasn't found in the server (due to
reconnection). The commands COM_STMT_SEND_LONG_DATA and COM_STMT_CLOSE
should not send any packets, even error packets should not be sent since
they are not expected by the client API.
The solution is to clear generated during the execution of the aforementioned
commands and to skip resend of prepared statement commands. Another fix is
that if the connection breaks during the send of prepared statement command,
the command is not sent again since the prepared statement is no longer in the
server.
libmysql/libmysql.c:
The mysql handle might be reset after a reconnection.
Pass the now used stmt argument to cli_advanced_command.
sql-common/client.c:
Don't resend command if the connection broke and it's a prepared
statement command. If the session is broken, prepared statements
on the server are gone, set the error accordanly.
sql/sql_prepare.cc:
Clear any error set during the execution of the request
command.
tests/mysql_client_test.c:
Fix memory leak by freeing result associated with statement.
Remove test case for Bug 29948 because it's not reliable in
5.0 (fixed in 5.1) due to KILL queries sending two packets for
a thread that kills itself.
Queries like:
SELECT ROW(1, 2) IN (SELECT t1.a, 2)
FROM t1 GROUP BY t1.a
or
SELECT ROW(1, 2) IN (SELECT t1.a, 2 FROM t2)
FROM t1 GROUP BY t1.a
lead to assertion failure in the
Item_in_subselect::row_value_transformer method in debugging
build, or to unexpected error message in release build:
ERROR 1247 (42S22): Reference '<list ref>' not supported (forward
reference in item list)
Unexpected error message and assertion failure have been
eliminated.
mysql-test/r/subselect3.result:
Added test case for bug #34763.
mysql-test/t/subselect3.test:
Added test case for bug #34763.
sql/item.cc:
Fixed bug #34763.
The Item_ref::fix_fields method has been modified to silently
ignore not fixed outer references: by the definition, those
references should be fixed later by the call to the
fix_inner_refs function.
sql/item_subselect.cc:
Fixed bug #34763.
The Item_in_subselect::row_value_transformer method has been
modified to eliminate assertion failure on not fixed outer
references: by the definition those references are allowed in
this context and should be fixed later by the call to the
fix_inner_refs function.
into stella.local:/home2/mydev/mysql-5.1-axmrg
mysql-test/r/merge.result:
Auto merged
mysql-test/t/merge.test:
Auto merged
storage/myisammrg/ha_myisammrg.cc:
Auto merged
sql/sql_yacc.yy:
Manual merge
into pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.1
configure.in:
Auto merged
mysql-test/r/func_misc.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/r/partition.result:
Auto merged
mysql-test/r/partition_symlink.result:
Auto merged
mysql-test/t/func_misc.test:
Auto merged
mysql-test/t/partition.test:
Auto merged
sql/field.cc:
Auto merged
sql/field.h:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/log.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/partition_info.cc:
Auto merged
sql/partition_info.h:
Auto merged
sql/rpl_rli.cc:
Auto merged
sql/sql_plugin.cc:
Auto merged
sql/sql_show.cc:
Auto merged
mysql-test/r/symlink.result:
manual merge
mysql-test/suite/parts/inc/partition_basic.inc:
manual merge
mysql-test/suite/parts/r/partition_basic_innodb.result:
manual merge
mysql-test/suite/parts/r/partition_basic_myisam.result:
manual merge
mysql-test/t/partition_symlink.test:
manual merge
mysql-test/t/symlink.test:
manual merge
sql/sql_parse.cc:
manual merge
into pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.0
mysql-test/r/func_misc.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/t/func_misc.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.cc:
Auto merged
into dl145h.mysql.com:/data0/mkindahl/mysql-5.1-rpl
mysql-test/include/commit.inc:
Auto merged
mysql-test/lib/mtr_report.pl:
Auto merged
mysql-test/r/commit_1innodb.result:
Auto merged
mysql-test/r/variables.result:
Auto merged
mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result:
Auto merged
mysql-test/t/variables.test:
Auto merged
sql/handler.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/log.cc:
Auto merged
sql/rpl_rli.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
mysql-test/extra/rpl_tests/rpl_loaddata.test:
Removing SHOW MASTER STATUS that does not seem to make sense.
mysql-test/extra/rpl_tests/rpl_log.test:
Correcting test case to sync slave with master.
mysql-test/suite/binlog/r/binlog_unsafe.result:
Result change.
mysql-test/suite/binlog/t/binlog_unsafe.test:
Removing unsafe variable from list of safe variables.
mysql-test/suite/rpl/r/rpl_loaddata.result:
Result change.
mysql-test/suite/rpl/r/rpl_skip_error.result:
Result change.
mysql-test/suite/rpl/t/rpl_skip_error.test:
Correcting bad manual+automatic merge. Test is now only relevant for statement-
based replication.
sql/rpl_rli.cc:
Correcting automerge undoing previous change of return value.
Relay_log_info::wait_for_pos() should return -2 when not initialized to work
correctly.
into mysql.com:/home/svoj/devel/mysql/BUG28248/mysql-5.1-engines
mysql-test/r/merge.result:
Auto merged
mysql-test/t/merge.test:
Auto merged
storage/myisammrg/ha_myisammrg.cc:
Auto merged
sql/sql_yacc.yy:
After merge fix.
When there are no underlying tables specified for a merge table,
SHOW CREATE TABLE outputs a statement that cannot be executed. The
same is true for mysqldump (it generates dumps that cannot be
executed).
This happens because SQL parser does not accept empty UNION() clause.
This patch changes the following:
- it is now possible to execute CREATE/ALTER statement with
empty UNION() clause.
- the same as above, but still worth noting: it is now possible to
remove underlying tables mapping using ALTER TABLE ... UNION=().
- SHOW CREATE TABLE does not output UNION() clause if there are
no underlying tables specified for a merge table. This makes
mysqldump slightly smaller.
mysql-test/r/merge.result:
A test case for BUG#28248.
mysql-test/t/merge.test:
A test case for BUG#28248.
sql/ha_myisammrg.cc:
Do not output UNION clause in SHOW CREATE TABLE, when there are
no underlying tables defined.
sql/sql_yacc.yy:
Make underlying table list for MERGE engine optional.
As for MERGE engine empty underlying tables list is valid, it should
be valid for the parser as well.
This change is mostly needed to restore dumps made by earlier MySQL
versions. Also with this fix it is possible to remove underlying
tables mapping by using ALTER TABLE ... UNION=().
into trift2.:/MySQL/M51/push-5.1
client/mysqldump.c:
Auto merged
configure.in:
Auto merged
include/my_global.h:
Auto merged
scripts/mysql_config.sh:
Auto merged
sql/mysqld.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/unireg.h:
Auto merged
configure.in:
Auto merged
mysql-test/r/func_misc.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/r/partition.result:
Auto merged
mysql-test/r/partition_symlink.result:
Auto merged
mysql-test/t/func_misc.test:
Auto merged
mysql-test/t/partition.test:
Auto merged
sql/field.cc:
Auto merged
sql/field.h:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/log.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/partition_info.cc:
Auto merged
sql/partition_info.h:
Auto merged
sql/rpl_rli.cc:
Auto merged
sql/sql_plugin.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_parse.cc:
Manual merge. Needs later fix. New code in create table was not
accepted. Needs to be added to mysql_create_table_no_lock().
referenced_key_name field can be uninitialized in the case when
referenced table is dropped.
Added codition which allows to handle this situation.
mysql-test/r/information_schema_inno.result:
test result
mysql-test/t/information_schema_inno.test:
test result
sql/sql_show.cc:
referenced_key_name field can be uninitialized in the case when
referenced table is dropped.
Added codition which allows to handle this situation.
into stella.local:/home2/mydev/mysql-5.0-axmrg
mysql-test/r/func_misc.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/t/func_misc.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.cc:
Auto merged
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.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
