HANG IN PREPARING WITH 100% CPU USAGE
Infinite loop in the subselect_indexsubquery_engine::exec()
function caused Server hang with 100% CPU usage.
The BLACKHOLE storage engine didn't update handler's
table->status variable after index operations, that
caused an infinite "while(!table->status)" execution.
Index access methods of the BLACKHOLE engine handler
have been updated to set table->status variable to
STATUS_NOT_FOUND or 0 when such a method returns a
HA_ERR_END_OF_FILE error or 0 respectively.
mysql-test/r/blackhole.result:
Bug #11880012: INDEX_SUBQUERY, BLACKHOLE,
HANG IN PREPARING WITH 100% CPU USAGE
New test file for the BLACKHOLE engine.
mysql-test/t/blackhole.test:
Bug #11880012: INDEX_SUBQUERY, BLACKHOLE,
HANG IN PREPARING WITH 100% CPU USAGE
New test file for the BLACKHOLE engine.
storage/blackhole/ha_blackhole.cc:
Bug #11880012: INDEX_SUBQUERY, BLACKHOLE,
HANG IN PREPARING WITH 100% CPU USAGE
Index access methods of the BLACKHOLE engine handler
have been updated to set table->status variable to
STATUS_NOT_FOUND or 0 when such a method returns a
HA_ERR_END_OF_FILE error or 0 respectively, like
we do in MyISAM storage engine.
Now when rolling back a transaction on a blackhole table,
the transaction will not be written to the binlog.
sql/ha_blackhole.h:
Added support for transactions
mysql-test/t/blackhole.test:
Added a test for transaction support
mysql-test/r/blackhole.result:
updated test results for transaction support
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
no rows of the blackhold engine (for this engine to be a binlog propagator).
NOTE: blackhole.test currently hangs in 5.0 BUG#10175 so I'll merge without running this test; the
person who fixes the hang will correct the merged blackhole.result or ask me to).
mysql-test/r/blackhole.result:
result update
mysql-test/t/blackhole.test:
checking that statements get into binlog even when they were affecting
no rows of the blackhold engine. So that this engine can serve as
a binlog propagator (A->B->C replication where B has only blackhole tables,
B receives binlog from A, applies it to blackhole tables, writes statements
to its binlog which it sends to C; both A and C have non-blackhole tables). B is just a proxy.
configure.in:
Adding logic to run blackhole configure option.
mysql-test/r/blackhole.result:
Correction this, but I think I need to see why the warning is being generated in the first place.
acinclude.m4:
Change in message
mysql-test/r/blackhole.result:
Lowered the number of inserts.
mysql-test/t/blackhole.test:
Lowered the number of inserts.
sql/ha_blackhole.cc:
Added indexes per Serg, correction of indention, added asserts per Serg.
sql/ha_blackhole.h:
Indention fix, added methods for index...
acinclude.m4:
New macro rule for ha_blackhole.
configure.in:
Rule enabling blackhole engine
sql/Makefile.am:
Additions to Makefile for blackhole engine
sql/handler.cc:
Ifdef enable code for blackhole (and message for "what does this thing do").
sql/handler.h:
Flag for storage engine type.
sql/mysql_priv.h:
Added blackhole type.
sql/mysqld.cc:
Updates for building backhole.
sql/set_var.cc:
Show variable for blackhole engine
