in optimized build)
Unlike in autotools build, innodb was compiled with
-DUNIV_MUST_NOT_INLINE set. this exposed what
seems to be a bug in gcc backend.
The fix is to remove extra definition.
- package some more perl scripts on Windows (mysqlhotcopy and mysqldumpslow)
- do not try to pack .map files (no more produced)
- (CMake-unrelated) fix debug build on FreeBSD, trying to use uninitialized attribute
MY_MUTEX_INIT_FAST
All numeric operators and functions on integer, floating point
and DECIMAL values now throw an 'out of range' error rather
than returning an incorrect value or NULL, when the result is
out of supported range for the corresponding data type.
Some test cases in the test suite had to be updated
accordingly either because the test case itself relied on a
value returned in case of a numeric overflow, or because a
numeric overflow was the root cause of the corresponding bugs.
The latter tests are no longer relevant, since the expressions
used to trigger the corresponding bugs are not valid anymore.
However, such test cases have been adjusted and kept "for the
record".
Corrected some packaging bugs:
- install mysqlservices library
- install libmysqlclient_r.so.{16,16.0.0} as links
to libmysqlclient.so
- install libmysqld-debug.a
- install my_safe_process, my_safe_kill and
symlinks to mysql-test-run.pl (mtr, mysql-test-run)
into correct place ${INSTALL_MYSQLTESTDIR}
In BUG#49562 we fixed the case where numeric user var events
would not serialize the flag stating whether the value was signed
or unsigned (unsigned_flag). This fixed the case that the slave
would get an overflow while treating the unsigned values as
signed.
In this bug, we find that the unsigned_flag can sometimes change
between the moment that the user value is recorded for binlogging
purposes and the actual binlogging time. Since we take the
unsigned_flag from the runtime variable data, at binlogging time,
and the variable value is comes from the copy taken earlier in
the execution, there may be inconsistency in the
User_var_log_event between the variable value and its
unsigned_flag.
We fix this by also copying the unsigned_flag of the
user_var_entry when its value is copied, for binlogging
purposes. Later, at binlogging time, we use the copied
unsigned_flag and not the one in the runtime user_var_entry
instance.
Non-determinism of the test was caused by lack of setting a proper value to hb period,
actually fixed by BUG@50767.
These fixes aim at possible non-determinism in comparison of received
hb events by master and slave in the circular part of the test.
Even though the HB periods ratio was choosen to be as high as 10, it's still incorrect
to compare number of hb-events basing only a relation between their periods.
Yet another issue is relatively short 60 secs timeout of wait_for_status_var.inc
makes valgrind runs to fail.
Fixed with deploying wait_for_slave_io_to_start afront of calling wait_for_status_var.
The test is made runnable only with MIXED binlog-format as it has close to 1 min
total exec time and there is nothing format specific in it.
DDL no longer aborts mysql_lock_tables(), and hence
we no longer need to support need_reopen flag of this
call.
Remove the flag, and all the code in the server
that was responsible for handling the case when
it was set. This allowed to simplify:
open_and_lock_tables_derived(), the delayed thread,
multi-update.
Rename MYSQL_LOCK_IGNORE_FLUSH to MYSQL_OPEN_IGNORE_FLUSH,
since we now only support this flag in open_table().
Rename MYSQL_LOCK_PERF_SCHEMA to MYSQL_LOCK_LOG_TABLE,
to avoid confusion.
Move the wait for the global read lock for cases
when we do updates in SELECT f1() or DO (UPDATE) to
open_table() from mysql_lock_tables(). When waiting
for the read lock, we could raise need_reopen flag,
which is no longer present in mysql_lock_tables().
Since the block responsible for waiting for GRL
was moved, MYSQL_LOCK_IGNORE_GLOBAL_READ_LOCK
was renamed to MYSQL_OPEN_IGNORE_GLOBAL_READ_LOCK.
This deadlock could occour betweeen one connection executing
SET GLOBAL EVENT_SCHEDULER= ON and another executing SET GLOBAL
EVENT_SCHEDULER= OFF. The bug was introduced by WL#4738.
The first connection would hold LOCK_event_metadata (protecting
the global variable) while trying to lock LOCK_global_system_variables
starting the event scheduler thread (in THD:init()).
The second connection would hold LOCK_global_system_variables
while trying to get LOCK_event_scheduler after stopping the event
scheduler inside event_scheduler_update().
This patch fixes the problem by not using LOCK_event_metadata to
protect the event_scheduler variable. It is still protected using
LOCK_global_system_variables. This fixes the deadlock as it removes
one of the two mutexes used to produce it.
However, this patch opens up the possibility that the event_scheduler
variable and the real event_scheduler state can become out of sync
(e.g. variable = OFF, but scheduler running). But this can only
happen under very unlikely conditions - two concurrent SET GLOBAL
statments, with one thread interrupted at the exact wrong moment.
This is preferable to having the possibility of a deadlock.
This patch also fixes a bug where it was possible to exit create_event()
without releasing LOCK_event_metadata if running out of memory during
its exection.
No test case added since a repeatable test case would have required
excessive use of new sync points. Instead we rely on the fact that
this bug was easily reproduceable using RGQ tests.
When building the script directory using a CMake-based build, both the
variables in config.h.cmake (including PLUGINDIR) and the variables in
CMakeList.txt (which includes pkgplugindir).
However, for autotools-based builds, only pkgplugindir is substituted,
which means that the plugin-path is not substituted.
This patch solves the problem by using pkgplugindir, which works on both
CMake-based and autotools-based builds, instead of PLUGINDIR.
There are two issues fixed here:
1. We needed to update the result file, for some of
mysqlbinlog_* tests, because now the some padding chars
are not output anymore.
2. We needed to change the Field_string::pack so that
for BINARY types the padding chars are not packed
(lengthsp will return full length for these types).
Unquoted ${CMAKE_CPACK_COMMAND} is used in this script.
This variable resolves to cpack's real path with spaces, e.g
/Applications/CMake 2.6.4-app/Contents/bin/cpack.
Script fails due to lack of quotes.
Fix is to use quotes around ${CMAKE_CPACK_COMMAND}.
The problem is introduced by WL#4435 "Support OUT-parameters in
prepared statements".
When a statement that has out parameters was reprepared,
the reprepare request error was ignored, and an
attempt to send out parameters to the client was made.
Since the out parameter list was not initialized in case
of an error, this attempt led to a crash.
Don't try to send out parameters to the client
if an error occurred in statement execution.
- Fixing crash on attempt to create a fulltext index with an utf8mb4 column
- fixing wrong border width for supplementary characters in mysql client:
mysql --default-character-set=utf8mb4 -e "select concat(_utf32 0x20000,'a')"
Split rpl_row_charset into:
- rpl_row_utf16.
- rpl_row_utf32.
This way these tests can run independently if server supports
either one of the charsets but not both.
Cleaned up rpl_row_utf32 which had a spurious instruction:
-- let $reset_slave_type_conversions= 0
In BUG#51787 we were using the wrong charset to print out the
data. We were using the field charset for the string that would
hold the information. This caused the assertion, because the
string length was not aligned with UTF32 bytes requirements for
storage.
We fix this by using &my_charset_latin1 in the string object
instead of the field->charset(). As a side-effect, we needed to
extend the show_sql_type interface so that it took the field
charset is now passed as a parameter, so that one is able to
calculate the correct field size.
In BUG#51716 we had issues with Field_string::pack and
Field_string::unpack. When packing, the length was incorrectly
calculated. When unpacking, the padding the string would be
padded with the wrong bytes (a few bytes less than it should).
We fix this by resorting to charset abstractions (functions) that
calculate the correct length when packing and pad correctly the
string when unpacking.
