Remove warnings from test logs about depricated options
mysql-test/t/events_logs_tests-master.opt:
Remove warnings from test logs about depricated options
mysql-test/t/log_tables-big-master.opt:
Remove warnings from test logs about depricated options
mysql-test/t/log_tables-master.opt:
Remove warnings from test logs about depricated options
mysql-test/t/multi_statement-master.opt:
Remove warnings from test logs about depricated options
mysql-test/t/ps-master.opt:
Remove warnings from test logs about depricated options
mysql-test/t/show_check-master.opt:
Remove warnings from test logs about depricated options
mysql-test/t/slow_query_log_file_basic-master.opt:
Remove warnings from test logs about depricated options
mysql-test/t/slow_query_log_file_func-master.opt:
Remove warnings from test logs about depricated options
mysql-test/t/union-master.opt:
Remove warnings from test logs about depricated options
sql/mysqld.cc:
Don't give warnings for empty log file names
mysql-test/mysql-test-run.pl:
Remove warnings in log about depricated mysqld options
storage/maria/ma_state.c:
More DBUG_PRINT
storage/maria/trnman.c:
Fixed wrong test if commit_trid is visible
mysql-test/suite/maria/r/maria-recovery3.result:
result.
mysql-test/suite/maria/t/maria-recovery3-master.opt:
usual recovery test options
mysql-test/suite/maria/t/maria-recovery3.test:
Test for BUG#41037. Without the bugfix, the test would hang because Recovery would fail with "undo_key_insert got error 126": Recovery would believe INSERT of 2 is uncommitted, try to execute its UNDO_KEY_INSERT, fail to find the key to delete because DELETE deleted it. That failure of _ma_ck_real_delete() would mark table as corrupted (see
in d_search()) which is error 126 (HA_ERR_CRASHED).
storage/maria/ma_blockrec.c:
set trn->rec_lsn to LSN of commit record, when writing it.
storage/maria/ma_blockrec.h:
new function
storage/maria/ma_commit.c:
when committing or rolling back, rec_lsn should be LSN_IMPOSSIBLE: assertion is moved here
from trnman_end_trn(), because now ma_commit() can set rec_lsn and so when we reach trnman_end_trn()
it's not LSN_IMPOSSIBLE anymore.
Adding debug possibility to pause between COMMIT record write and trnman_commit_trn(), to be
able to fire checkpoint in between.
storage/maria/ma_loghandler.c:
in-write hook for COMMIT records
storage/maria/ma_recovery.c:
More debugging info in maria_recovery.trace, to see how the starting point of REDO phase is determined
storage/maria/trnman.c:
assertion cannot be here anymore see ma_commit.c
mysql-test/include/maria_empty_logs.inc:
move mysqladmin call to include file for reusal (so that others don't have to hit the same bug in their tests);
this include file additionally waits for disconnection. Reasons for BUG#41102:
- in maria-no-logging.test, we shut down mysqld in maria_empty_logs.inc, remove logs, tell mtr that it can
restart mysqld, then wait for being connected (wait_until_connected_again.inc), then send commands to new mysqld.
- but under Windows "mysqladmin shutdown" does not wait for mysqld to be down, so we accidentally removed logs
while it was shutting down, wait_until_connected_again found that we were connected (because it was shutting
down slowly, connections were not yet broken), sent new commands, and one of them failed because mysqld finally
closed connections.
- the fix is to just wait for disconnection after shutdown.
- in a sense, the catch is the "again" in wait_until_connected_again.inc...
mysql-test/include/mysqladmin_shutdown.inc:
shutdown with mysqladmin AND waiting for shutdown to complete (needed on Windows)
mysql-test/include/wait_until_connected_again.inc:
comment
mysql-test/include/wait_until_disconnected.inc:
script which waits until connection is lost
mysqlslap: fix a crash when mysql_store_result() fails
client/mysqlslap.c:
fix a crash
dbug/dbug.c:
only do safemalloc checks if a function is selected
mysql-test/mysql-test-run.pl:
it's easier to add new gdb parameters this way
storage/maria/ma_open.c:
typo in a comment
Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds
during the leap second.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time
representations) with leap seconds (ending on :59:60 or 59:61) will still be
considered illegal and discarded by the server with an error or
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.
mysql-test/r/timezone3.result:
Bug #39920: test case
mysql-test/std_data/Moscow_leap:
Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i
to accomodate for the 2008 leap second
mysql-test/t/timezone3.test:
Bug #39920: test case
sql/tztime.cc:
Bug #39920: adjust leap seconds (:60 or :61) to :59
sql/tztime.h:
Bug #39920: adjust leap seconds (:60 or :61) to :59
(BUG#41127: Maria: assertion when SHOW ENGINE MARIA LOGS and missing logs)
mysql-test/suite/maria/r/maria_showlog_error.result:
test suite for the BUG#41127
mysql-test/suite/maria/t/maria_showlog_error.test:
test suite for the BUG#41127
storage/maria/ha_maria.cc:
Do not use MY_WME in the stat call which errors we process on high level.
by using and taking out a full path.
mysql-test/r/ctype_filesystem.result:
Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem-master.opt:
Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem.test:
Bug #37399: use MYSQL_TEST_DIR rooted test
an item was evaluated unnecessary, fix that by checking preconditions before evaluating the item
sql/sql_select.cc:
an item was evaluated unnecessary, fix that by checking preconditions before evaluating the item
leads to an assertion failure
Any run-time error in stored function (like recursive function
call or update of table that is already updating by statement
which invoked this stored function etc.) that was used in some
expression of the single-table UPDATE statement caused an
assertion failure.
Multiple-table UPDATE (as well as INSERT and both single- and
multiple-table DELETE) are not affected.
mysql-test/r/update.result:
Added test case for bug #40745.
mysql-test/t/update.test:
Added test case for bug #40745.
sql/sql_update.cc:
Bug #40745: Error during WHERE clause calculation in UPDATE
leads to an assertion failure
The mysql_update function has been updated to take into account
the status of invoked stored functions before setting the status
of whole UPDATE query to OK.
an error
Even after the fix for bug 28701 visible behaviors of
SELECT FROM a view and SELECT FROM a regular table are
little bit different:
1. "SELECT FROM regular table USE/FORCE/IGNORE(non
existent index)" fails with a "ERROR 1176 (HY000):
Key '...' doesn't exist in table '...'"
2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
with a "ERROR 1221 (HY000): Incorrect usage of
USE/IGNORE INDEX and VIEW". OTOH "SHOW INDEX FROM
view" always returns empty result set, so from the point
of same behaviour view we trying to use/ignore non
existent index.
To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.
mysql-test/r/view.result:
Added test case for bug #33461.
Updated test case for bug 28701.
mysql-test/t/view.test:
Added test case for bug #33461.
Updated test case for bug 28701.
sql/sql_view.cc:
Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws
an error
To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.
The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES
were assuming that all the system variables are in system charset (UTF-8).
However the variables that are settable through command line will have a different
character set (character_set_filesystem).
Fixed the server to remember the correct character set of basedir, datadir, tmpdir,
ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave
variables and use it when processing data.
mysql-test/r/ctype_filesystem.result:
Bug #37339: test case (should be in utf-8)
mysql-test/t/ctype_filesystem-master.opt:
Bug #37339: test case (should be in ISO-8859-1)
mysql-test/t/ctype_filesystem.test:
Bug #37339: test case
sql/mysqld.cc:
Bug #37339: remember the correct character set for init_slave and init_connect
sql/set_var.cc:
Bug #37339:
- remember the character set of the relevant variables
- implement storing and using the correct
character set
sql/set_var.h:
Bug #37339: implement storing and using the correct
character set
sql/sql_show.cc:
Bug #37339: implement storing and using the correct
character set
bug is actually a weirdness in test system, so moving test portion into maria_notembedded.test
mysql-test/suite/maria/r/maria.result:
result update
mysql-test/suite/maria/r/maria_notembedded.result:
result update
mysql-test/suite/maria/t/maria.test:
Removing test portion into maria_notembedded.test. Explanation below.
Running maria.test with --mem --embedded --valgrind I got:
==378== Invalid read of size 4
==378== at 0x857C755: _lf_pinbox_real_free (lf_alloc-pin.c:342)
==378== by 0x857C640: _lf_pinbox_free (lf_alloc-pin.c:267)
==378== by 0x857D50C: ldelete (lf_hash.c:226)
==378== by 0x857DBC1: lf_hash_delete (lf_hash.c:429)
==378== by 0x8243D82: unlock_lock_and_free_resource
(waiting_threads.c:676)
==378== by 0x8244A79: wt_thd_release (waiting_threads.c:948)
==378== by 0x83F301D: wt_thd_release_self (trnman.c:98)
==378== by 0x83F3D49: trnman_end_trn (trnman.c:431)
==378== by 0x837C437: ma_commit (ma_commit.c:60)
==378== by 0x835F082: ha_maria::external_lock(THD*, int)
(ha_maria.cc:2387)
==378== by 0x84D1011: handler::ha_external_lock(THD*, int)
(handler.cc:4433)
==378== by 0x856DA92: unlock_external(THD*, st_table**, unsigned)
(lock.cc:786)
==378== by 0x856DD6F: mysql_unlock_tables(THD*, st_mysql_lock*)
(lock.cc:389)
==378== by 0x8274A57: close_thread_tables(THD*) (sql_base.cc:1307)
==378== by 0x82ABEC3: unlock_locked_tables(THD*) (sql_parse.cc:99)
==378== by 0x82B0BB3: mysql_execute_command(THD*)
(sql_parse.cc:3372)
==378== Address 0x5894a0c is 164 bytes inside a block of size 184
free'd
==378== at 0x40233FC: free (vg_replace_malloc.c:323)
==378== by 0x823CF92: my_thread_end (my_thr_init.c:348)
==378== by 0x8200FEE: mysql_thread_end (libmysql.c:250)
==378== by 0x81A9487: send_one_query (mysqltest.c:535)
==378== by 0x4050111: start_thread (in /lib/libpthread-2.5.so)
==378== by 0x41A52ED: clone (in /lib/libc-2.5.so)
(among other errors). The line where the invalid read happens is:
if (available_stack_size(&pinbox, *pins->stack_ends_here) >
alloca_size)
and stack_ends_here was previously set here:
el->stack_ends_here= & my_thread_var->stack_ends_here;
The mysqltest "send" command, in embedded mode, is implemented this way
(mysqltest.c:do_send_query()): a *new OS thread* is created in
mysqltest, and does this:
mysql_thread_init();
VOID(mysql_send_query(&cn->mysql, cn->cur_query,
cn->cur_query_len));
mysql_thread_end();
So, con_d "send insert t1 values (2)" creates a new OS thread, which
gets a thread-specific data (mysql_thread_init()), then sends the
query; in particular, this sets el->stack_ends_here to a pointer inside
the thread-specific data (see my_thread_var above), that is, thd->pins
depends on the thread-specific data.
This sent "insert" blocks as expected, thread-specific data is free()d
(my_thread_end() above), OS thread terminates.
Then "default" connection runs "insert t1 values (3)"
which blocks on the 3 already inserted by the con_d.
This blocking (see waiting_threads.c) creates a WT_RESOURCE, which has,
as owner, con_d's WT_THD.
When con_d calls "unlock tables" (see stack trace), it wants to release
this resource, which involves con_d's thd->pins, so it ends up reading
stack_ends_here which points inside the freed thread-specific data =>
Valgrind error, crashes...
So this is an effect of having one single connection (con_d) for which
two queries:
send insert t1 values (2)
unlock tables
are done by different OS threads. That is indeed weird design of
mysqltest, and it breaks on the dependency of lf_alloc-pin.c on
thread-specific data. It is maybe already explained in those comments
in lf_alloc-pin.c:
" It is assumed that pins belong to a THD and are not transferable
between THD's (LF_PINS::stack_ends_here being a primary reason
for this limitation)."
" It is assumed that pins belong to a thread and are not
transferable
between threads."
In correct usage of libmysqld (no two queries sent for one connection
by two threads), this problem would not happen, so I call it a
deficiency of the test system.
mysql-test/suite/maria/t/maria_notembedded.test:
moving test portion into maria_notembedded.test
The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win,
If MySQL is compiled with valgrind there are errors about
using of uninitialized variable(orig_table).
The fix is to set field->orig_table correct value.
mysql-test/r/innodb_mysql.result:
test result
mysql-test/t/innodb_mysql.test:
test case
sql/sql_base.cc:
set field->orig_table to 'table' value because it may be bogus and
it leads to crash on Field_string::type() function.
Reason for the failing test was that "SELECT count(*) from mysql.general_log;" was not always
the same number. That was fixed by "...count(*)>4..." as the minimal fulfilled condition.
As Bug 35371 was fixed the testcase with "log_output = 'FILE'" was enabled and changed to have
always the same result.
enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())
mysql-test/r/subselect.result:
test result
mysql-test/t/subselect.test:
test case
sql/mysql_priv.h:
added UNCACHEABLE_CHECKOPTION flag
sql/sql_update.cc:
enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())
