When issuing a 'SET GLOBAL SQL_SLAVE_SKIP_COUNTER' statement, the previous
position along with the new position is dumped into the error log. Namely,
the following information is printed out: skip_counter, group_relay_log_name
and group_relay_log_pos.
When issuing a 'CHANGE MASTER TO' statement, key elements of the previous
state, namely the host, port, the master_log_file and the master_log_pos
are dumped into the error log.
Iterative patch improvement. Previously committed patch
caused wrong result on Windows. The previous patch also
broke secure_file_priv for symlinks since not all file
paths which must be compared against this variable are
normalized using the same norm.
The server variable opt_secure_file_priv wasn't
normalized properly and caused the operations
LOAD DATA INFILE .. INTO TABLE ..
and
SELECT load_file(..)
to do different interpretations of the
--secure-file-priv option.
The patch moves code to the server initialization
routines so that the path always is normalized
once and only once.
It was also intended that setting the option
to an empty string should be equal to
lifting all previously set restrictions. This
is also fixed by this patch.
mysql-test/r/loaddata.result:
* Removed test code which will currently break the much used --mem feature of mtr.
mysql-test/t/loaddata.test:
* Removed test code which will currently break the much used --mem feature of mtr.
sql/item_strfunc.cc:
* Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
sql/mysql_priv.h:
* Added signature for is_secure_file_path()
sql/mysqld.cc:
* New function for checking if a path compatible with the secure path restriction.
* Added initialization of the opt_secure_file_priv variable.
sql/sql_class.cc:
* Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
sql/sql_load.cc:
* Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
The server was not checking the supplied to COM_FIELD_LIST table name
for validity and compliance to acceptable table names standards.
Fixed by checking the table name for compliance similar to how it's
normally checked by the parser and returning an error message if
it's not compliant.
WHERE predicates containing references to empty tables in a
subquery were handled incorrectly by the optimizer when
executing EXPLAIN. As a result, the optimizer could try to
evaluate such predicates rather than just stop with
"Impossible WHERE noticed after reading const tables" as
it would do in a non-subquery case. This led to valgrind
errors and crashes.
Fixed the code checking the above condition so that subqueries
are not excluded and hence are handled in the same way as top
level SELECTs.
mysql-test/r/explain.result:
Added a test case for bug #48419.
mysql-test/r/ps.result:
Updated test results to take the new (and more correct)
"Extra" comments in execution plans.
mysql-test/t/explain.test:
Added a test case for bug #48419.
sql/sql_select.cc:
There is no point in excluding subqueries from checking
for identically false WHERE conditions.
The server could be tricked to read packets indefinitely if it
received a packet larger than the maximum size of one packet.
This problem is aggravated by the fact that it can be triggered
before authentication.
The solution is to no skip big packets for non-authenticated
sessions. If a big packet is sent before a session is authen-
ticated, a error is returned and the connection is closed.
include/mysql_com.h:
Add skip flag. Only used in server builds.
sql/net_serv.cc:
Control whether big packets can be skipped.
Problem: "COM_FIELD_LIST is an old command of the MySQL server, before there was real move to only
SQL. Seems that the data sent to COM_FIELD_LIST( mysql_list_fields() function) is not
checked for sanity. By sending long data for the table a buffer is overflown, which can
be used deliberately to include code that harms".
Fix: check incoming data length.
sql/sql_parse.cc:
Fix for bug #53237: mysql_list_fields/COM_FIELD_LIST stack smashing
- check incoming mysql_list_fields() table name arg length.
The problem was in an incorrect debug assertion. The expression
used in the failing assertion states that when finding
references matching ORDER BY expressions, there can be only one
reference to a single table. But that does not make any sense,
all test cases for this bug are valid examples with multiple
identical WHERE expressions referencing the same table which
are also present in the ORDER BY list.
Fixed by removing the failing assertion. We also have to take
care of the 'found' counter so that we count multiple
references only once. We rely on this fact later in
eq_ref_table().
mysql-test/r/join.result:
Added a test case for bug #50335.
mysql-test/t/join.test:
Added a test case for bug #50335.
sql/sql_select.cc:
Removing the assertion in eq_ref_table() as it does not make
any sense. We also have to take care of the 'found' counter so
that we count multiple references only once. We rely on this
fact later in eq_ref_table().
of sync
In RBR, sometimes the table->s->last_null_bit_pos can be zero. This
has impact at the slave when it compares records fetched from the
storage engine against records in the binary log event. If
last_null_bit_pos is zero the slave, while comparing in
log_event.cc:record_compare function, would set all bits in the last
null_byte to 1 (assumed all 8 were unused) . Thence it would loose the
ability to distinguish records that were similar in contents except
for the fact that some field was null in one record, but not in the
other. Ultimately this would cause wrong matches, and in the specific
case depicted in the bug report the same record would be updated
twice, resulting in a lost update.
Additionally, in the record_compare function the slave was setting the
X bit unconditionally. There are cases that the X bit does not exist
in the record header. This could also lead to wrong matches between
records.
We fix both by conditionally resetting the bits: (i) unused null_bits
are set if last_null_bit_pos > 0; (ii) X bit is set if
HA_OPTION_PACK_RECORD is in use.
mysql-test/extra/rpl_tests/rpl_record_compare.test:
Shared part of the test case for MyISAM and InnoDB.
mysql-test/suite/rpl/t/rpl_row_rec_comp_innodb.test:
InnoDB test case.
mysql-test/suite/rpl/t/rpl_row_rec_comp_myisam.test:
MyISAM test case. Added also coverage for Field_bits case.
sql/log_event.cc:
Deployed conditional setting of unused bits at record_compare.
sql/log_event_old.cc:
Same change as in log_event.cc.
Correcting a patch misstake. The converted file path is placed in 'buff' not in opt_secure_file_priv.
mysql-test/r/loaddata.result:
* Updated test case; Since secure_file_priv now is normalized the previous values are changed.
sql/mysqld.cc:
* Fixed patch misstake
The server variable opt_secure_file_priv wasn't
normalized properly and caused the operations
LOAD DATA INFILE .. INTO TABLE ..
and
SELECT load_file(..)
to do different interpretations of the
--secure-file-priv option.
The patch moves code to the server initialization
routines so that the path always is normalized
once and only once.
It was also intended that setting the option
to an empty string should be equal to
lifting all previously set restrictions. This
is also fixed by this patch.
sql/mysqld.cc:
* If --secure_file_option is an empty string then the option variable
should be unset.
* opt_secure_file_option should be normalized once when the server starts.
sql/sql_load.cc:
* moved variable normalization code to fix_paths()
Potential deadlock situation involving LOCK_plugin,
LOCK_global_system_variables and LOCK_status.
This patch backports the fix from next-mr, unlocking
LOCK_plugin before calling plugin->init() and
add_status_vars().
Arg_comparator initializes 'comparators' array in case of
ROW comparison and does not free this array on destruction.
It leads to memory leaks.
The fix:
-added Arg_comparator::cleanup() method which frees
'comparators' array.
-added Item_bool_func2::cleanup() method which calls
Arg_comparator::cleanup() method
mysql-test/r/ps.result:
test case
mysql-test/r/row.result:
test case
mysql-test/t/ps.test:
test case
mysql-test/t/row.test:
test case
sql/item_cmpfunc.h:
-added Arg_comparator::cleanup() method which frees
'comparators' array.
-added Item_bool_func2::cleanup() method which calls
Arg_comparator::cleanup() method
to cleanup open connections
It was possible to UNINSTALL storage engine plugin when binding
between THD object and storage engine is still active (e.g. in
the middle of transaction).
To avoid unclean deactivation (uninstall) of storage engine plugin
in the middle of transaction, additional storage engine plugin
lock is acquired by thd_set_ha_data().
If ha_data is not null and storage engine plugin was not locked
by thd_set_ha_data() in this connection before, storage engine
plugin gets locked.
If ha_data is null and storage engine plugin was locked by
thd_set_ha_data() in this connection before, storage engine
plugin lock gets released.
If handlerton::close_connection() didn't reset ha_data, server does
it immediately after calling handlerton::close_connection().
Note that this is just a framework fix, storage engines must switch
to thd_set_ha_data() from thd_ha_data() if they want to see fit.
include/mysql/plugin.h:
As thd_{get|set}_ha_data() have some extra logic now, they
must be implemented on server side.
include/mysql/plugin.h.pp:
As thd_{get|set}_ha_data() have some extra logic now, they
must be implemented on server side.
sql/handler.cc:
Make sure ha_data is reset and ha_data lock is released.
sql/handler.h:
hton is not supposed to be updated by ha_lock_engine(),
make it const.
sql/sql_class.cc:
As thd_{get|set}_ha_data() have some extra logic now, they
must be implemented on server side.
sql/sql_class.h:
Added ha_data lock.
We should disable const subselect item evaluation because
subselect transformation does not happen in view_prepare_mode
and thus val_...() methods can not be called.
mysql-test/r/ctype_ucs.result:
test case
mysql-test/r/view.result:
test case
mysql-test/t/ctype_ucs.test:
test case
mysql-test/t/view.test:
test case
sql/item.cc:
disabled const subselect item evaluation in
view prepare mode.
sql/item_subselect.cc:
added Item_subselect::safe_charset_converter which
prevents const item evaluation in view prepare mode.
sql/item_subselect.h:
added Item_subselect::safe_charset_converter which
prevents const item evaluation in view prepare mode.
The problem is that we can not use make_cond_for_table().
This function relies on used_tables() condition
which is not set properly for subqueries.
As result subquery is not filtered out.
The fix is to use remove_eq_conds() function instead
of make_cond_for_table() func. 'remove_eq_conds()'
algorithm relies on const_item() value and it allows
to handle subqueries in right way.
mysql-test/r/having.result:
test case
mysql-test/t/having.test:
test case
sql/sql_select.cc:
The fix is to use remove_eq_conds() function instead
of make_cond_for_table() function.
Procedure, while DECIMAL works
Selecting of the CONCAT(...<SP variable>...) result into
a user variable may return wrong data.
Item_func_concat::val_str contains a number of memory
allocation-saving tricks. One of them concatenates
strings inplace inserting the value of one string
at the beginning of the other string. However,
this trick didn't care about strings those points
to the same data buffer: this is possible when
a CONCAT() parameter is a stored procedure variable -
Item_sp_variable::val_str() uses the intermediate
Item_sp_variable::str_value field, where it may
store a reference to an external buffer.
The Item_func_concat::val_str function has been
modified to take into account val_str functions
(such as Item_sp_variable::val_str) that return
a pointer to an internal Item member variable
that may reference to a buffer provided.
mysql-test/r/func_concat.result:
Test case for the bug #40625.
mysql-test/t/func_concat.test:
Test case for the bug #40625.
sql/item_strfunc.cc:
Bug #40625: Concat fails on DOUBLE values in a Stored
Procedure, while DECIMAL works
The Item_func_concat::val_str function has been
modified to take into account val_str functions
(such as Item_sp_variable::val_str) that return
a pointer to an internal Item member variable
that may reference to a buffer provided.
on index
'my_decimal' class has two members which can be used to access the
value. The member variable buf (inherited from parent class decimal_t)
is set to member variable buffer so that both are pointing to same value.
Item_copy_decimal::copy() uses memcpy to clone 'my_decimal'. The member
buffer is declared as an array and memcpy results in copying the values
of the array, but the inherited member buf, which should be pointing at
the begining of the array 'buffer' starts pointing to the begining of
buffer in original object (which is being cloned). Further updates on
'my_decimal' updates only the inherited member 'buf' but leaves
buffer unchanged.
Later when the new object (which now holds a inconsistent value) is cloned
again using proper cloning function 'my_decimal2decimal' the buf pointer
is fixed resulting in loss of the current value.
Using my_decimal2decimal instead of memcpy in Item_copy_decimal::copy()
fixed this problem.
mysql-test/r/subselect.result:
Updated result file after addding test case for bug#47904.
mysql-test/t/subselect.test:
Added test case for bug#47904.
sql/item.cc:
Memcopy shouldn't be used to clone my_decimal. Use my_decimal2decimal
instead.
The problem was that a syntactically invalid trigger could cause
the server to crash when trying to list triggers. The crash would
happen due to a mishap in the backup/restore procedure that should
protect parser items which are not associated with the trigger. The
backup/restore is used to isolate the parse tree (and context) of
a statement from the load (and parsing) of a trigger. In this case,
a error during the parsing of a trigger could cause the improper
backup/restore sequence.
The solution is to properly restore the original statement context
before the parser is exited due to syntax errors in the trigger body.
mysql-test/r/trigger.result:
Add test case result for Bug#50755
mysql-test/t/trigger.test:
Add test case for Bug#50755
sql/sp_head.cc:
Merge sp_head::destroy() and sp_head destructor. Retrieve THD
from the LEX so that m_thd is not necessary.
sql/sql_lex.cc:
Explicitly restore the original environment.
during an UPDATE
Extended the fix for bug 29310 to multi-table update:
When a table is being updated it has two set of fields - fields required for
checks of conditions and fields to be updated. A storage engine is allowed
not to retrieve columns marked for update. Due to this fact records can't
be compared to see whether the data has been changed or not. This makes the
server always update records independently of data change.
Now when an auto-updatable timestamp field is present and server sees that
a table handle isn't going to retrieve write-only fields then all of such
fields are marked as to be read to force the handler to retrieve them.
The problem is that message resource (message.rc) is compiled as part of static library
sql.lib rather than with executable mysqld.exe. resource files do not work in static
libraries.
The fix is to add message.rc to mysqld.exe source files list.
Problem: ALTER TABLE ADD INDEX may lead to table copying if there's
numeric field(s) with non-default display width modificator specified.
Fix: compare numeric field's storage lenghts when we decide whether
they can be considered 'equal' for table alteration purposes.
mysql-test/r/error_simulation.result:
Fix for bug#50946: fast index creation still seems to copy the table
- test result.
mysql-test/t/error_simulation.test:
Fix for bug#50946: fast index creation still seems to copy the table
- test case.
sql/field.cc:
Fix for bug#50946: fast index creation still seems to copy the table
- check numeric field's pack lengths instead of it's display lenghts
comparing fields equality for table alteration purposes.
sql/sql_table.cc:
Fix for bug#50946: fast index creation still seems to copy the table
- check compare_tables() result for testing purposes.
Previously installed dynamic plugins are explicitly not loaded
on startup with --skip-grant-tables enabled. However, INSTALL
PLUGIN/UNINSTALL PLUGIN commands are allowed, and result in
inconsistent error messages (reporting duplicate plugin or
plugin does not exist).
This patch adds a check for --skip-grant-tables mode, and
returns error ER_OPTION_PREVENTS_STATEMENT to the user when
the above commands are attempted.
Problem: EXPLAIN EXTENDED was trying to resolve references to
freed temporary table fields for GROUP_CONCAT()'s ORDER BY arguments.
Fix: use stored original GROUP_CONCAT()'s arguments in such a case.
mysql-test/r/func_gconcat.result:
Fix for bug#52397: another crash with explain extended and group_concat
- test result.
mysql-test/t/func_gconcat.test:
Fix for bug#52397: another crash with explain extended and group_concat
- test case.
sql/item_sum.cc:
Fix for bug#52397: another crash with explain extended and group_concat
- use "pargs", printing ORDER BY arguments in the
Item_func_group_concat::print() instead of "order" to avoid
possible reference resolving to (freed) temporary table fields.
The crash is the result of an attempt made by JOIN::optimize to evaluate
the WHERE condition when no records have been actually read.
The fix is to remove erroneous 'outer_join' variable check.
mysql-test/r/join.result:
test result
mysql-test/t/join.test:
test case
sql/sql_select.cc:
removed erroneous 'outer_join' variable check.
The crash happens because greedy_serach
can not determine best plan due to
wrong inner table dependences. These
dependences affects join table sorting
which performs before greedy_search starting.
In our case table which has real 'no dependences'
should be put on top of the list but it does not
happen as inner tables have no dependences as well.
The fix is to exclude RAND_TABLE_BIT mask from
condition which checks if table dependences
should be updated.
mysql-test/r/join.result:
test result
mysql-test/t/join.test:
test case
sql/sql_select.cc:
RAND_TABLE_BIT mask should not be counted as it
prevents update of inner table dependences.
For example it might happen if RAND() function
is used in JOIN ON clause.
CHECK_FIELD_IGNORE was treated as CHECK_FIELD_ERROR_FOR_NULL;
UPDATE...SET...NULL on NOT NULL fields behaved differently after
a trigger.
Now distinguishes between IGNORE and ERROR_FOR_NULL and save/restores
check-field options.
mysql-test/r/trigger.result:
Show that UPDATE...SET...NULL on NOT NULL columns doesn't behave differently
when run after a trigger.
mysql-test/t/trigger.test:
Show that UPDATE...SET...NULL on NOT NULL columns doesn't behave differently
when run after a trigger.
sql/field_conv.cc:
CHECK_FIELD_IGNORE was treated as CHECK_FIELD_ERROR_FOR_NULL.
Distinguish between the two.
sql/sp_head.cc:
Raise error as needed.
sql/sql_class.cc:
Save and restore check-fields options.
sql/sql_class.h:
Make room so we can save check-fields options.
sql/sql_insert.cc:
Raise error as needed.
When mysqlbinlog was given the --database=X flag, it always printed
'ROLLBACK TO', but the corresponding 'SAVEPOINT' statement was not
printed. The replicated filter(replicated-do/ignore-db) and binlog
filter (binlog-do/ignore-db) has the same problem. They are solved
in this patch together.
After this patch, We always check whether the query is 'SAVEPOINT'
statement or not. Because this is a literal check, 'SAVEPOINT' and
'ROLLBACK TO' statements are also binlogged in uppercase with no
any comments.
The binlog before this patch can be handled correctly except one case
that any comments are in front of the keywords. for example:
/* bla bla */ SAVEPOINT a;
/* bla bla */ ROLLBACK TO a;
The log event of 'CREATE EVENT' was being binlogged with garbage
at the end of the query if 'CREATE EVENT' is followed by another SQL statement
and they were executed as one command.
for example:
DELIMITER |;
CREATE EVENT e1 ON EVERY DAY DO SELECT 1; SELECT 'a';
DELIMITER ;|
When binlogging 'CREATE EVENT', we always create a new statement with definer
and write it into the log event. The new statement is made from cpp_buf(preprocessed buffer).
which is not a c string(end with '\0'), but it is copied as a c string.
In this patch, cpp_buf is copied with its length.
The crash happens because of incorrect max_length calculation
in QUOTE function(due to overflow). max_length is set
to 0 and it leads to assert failure.
The fix is to cast expression result to
ulonglong variable and adjust it if the
result exceeds MAX_BLOB_WIDTH.
mysql-test/r/func_str.result:
test case
mysql-test/t/func_str.test:
test case
sql/item_strfunc.h:
cast expression result to ulonglong variable and
adjust it if the result exceeds MAX_BLOB_WIDTH.
Repairing MyISAM table with fulltext indexes and low
myisam_sort_buffer_size may crash the server.
Estimation of number of index entries was done incorrectly,
causing further assertion failure or server crash.
Docs note: min value for myisam_sort_buffer_size has been
changed from 4 to 4096.
mysql-test/r/fulltext.result:
A test case for BUG#51866.
mysql-test/r/myisam.result:
Min value for myisam_sort_buffer_size is 4096.
mysql-test/r/variables.result:
Min value for myisam_sort_buffer_size is 4096.
mysql-test/suite/sys_vars/r/myisam_sort_buffer_size_basic_32.result:
Min value for myisam_sort_buffer_size is 4096.
mysql-test/t/fulltext.test:
A test case for BUG#51866.
sql/mysqld.cc:
Min value for myisam_sort_buffer_size is 4096.
storage/myisam/mi_check.c:
When estimating number of index entries for external
fulltext parser, take into account that key_length may
be bigger than myisam_sort_buffer_size. Reuse logic
from _create_index_by_sort(): force MIN_SORT_BUFFER to
be min value for myisam_sort_buffer_size.
Another problem is that ftkey_nr has no other meaning
than serial number of fulltext index starting with 1.
We can't say if this key using built-in or external
parser basing on it's value. In other words we always
entered if-branch for external parser. At this point,
the only way to check if we use default parser is to
compare keyinfo::parser with &ft_default_parser.
storage/myisam/sort.c:
Get rid of MIN_SORT_MEMORY, use MIN_SORT_BUFFER instead
(defined in myisamdef.h, has the same value and purpose).
If the listed columns in the view definition of
the table used in a 'INSERT .. SELECT ..'
statement mismatched, a debug assertion would
trigger in the cache invalidation code
following the failing statement.
Although the find_field_in_view() function
correctly generated ER_BAD_FIELD_ERROR during
setup_fields(), the error failed to propagate
further than handle_select(). This patch fixes
the issue by adding a check for the return
value.
mysql-test/r/query_cache_with_views.result:
* added test for bug 46615
mysql-test/t/query_cache_with_views.test:
* added test for bug 46615
sql/sql_parse.cc:
* added check for handle_select() return code before attempting to invalidate the cache.
col equal to itself!
There's no need to copy the value of a field into itself.
While generally harmless (except for some performance penalties)
it may be dangerous when the copy code doesn't expect this.
Fixed by checking if the source field is the same as the destination
field before copying the data.
Note that we must preserve the order of assignment of the null
flags (hence the null_value assignment addition).
The reason of the failure was apparent flaw in that a pointer to an uninitialized buffer was
passed to DBUG_PRINT of Protocol_text::store().
Fixed with splitting the print-out into two branches:
one with length zero of the problematic arg and the rest.
sql/protocol.cc:
correcting DBUG_PRINT to print out `from' with a care because one may be uninitialized in the caller.
A failed REVOKE statement is logged with error=0, thus causing
the slave to stop. The slave should not stop as this was an
expected error. Given that the execution failed on the master as
well the error code should be logged so that the slave can replay
the statement, get an error and compare with the master's
execution outcome. If errors match, then slave can proceed with
replication, as the error it got, when replaying the statement,
was expected.
In this particular case, the bug surfaces because the error code
is pushed to the THD diagnostics area after writing the event to
the binary log. Therefore, it would be logged with the THD
diagnostics area clean, hence its error code would not contain
the correct code.
We fix this by moving the error reporting ahead of the call to
the routine that writes the event to the binary log.
(Original patch by Sinisa Milivojevic)
The YEAR(4) value of 2000 was equal to the "bad" YEAR(4) value of 0000.
The get_year_value() function has been modified to not adjust bad
YEAR(4) value to 2000.
mysql-test/r/type_year.result:
Test case for bug #49910.
mysql-test/t/type_year.test:
Test case for bug #49910.
sql/item_cmpfunc.cc:
Bug #49910: Behavioural change in SELECT/WHERE on YEAR(4) data type
The get_year_value() function has been modified to not adjust bad
YEAR(4) value to 2000.
The problem is that when we make conditon for
grouped result const part of condition is cut off.
It happens because some parts of 'having' condition
which refer to outer join become const after
make_join_statistics. These parts may be lost
during further having condition transformation
in JOIN::exec. The fix is adding 'having'
condition check for const tables after
make_join_statistics is performed.
mysql-test/r/having.result:
test case
mysql-test/t/having.test:
test result
sql/sql_select.cc:
added 'having' condition check for const tables
after make_join_statistics is performed.
DBUG_SYNC_POINT has at least one strong limitation that it's not defined
on all platforms. It has issues cooperating with @@debug.
All in all its functionality is superseded by DEBUG_SYNC facility and
there is no reason to maintain the old less flexible one.
Fixed with adding debug_sync_set_action() function as a facility to set up
a sync-action in the server sources code and re-writing existing simulations
(found 3) to use it.
Couple of tests have been reworked as well.
The patch offers a pattern for setting sync-points in replication threads
where the standard DEBUG_SYNC does not suffice to reach goals.
mysql-test/extra/rpl_tests/rpl_get_master_version_and_clock.test:
rewriting the test from GET_LOCK()-based to DEBUG_SYNC-based;
a pattern of usage DEBUG_SYNC for replication testing is provided.
mysql-test/suite/rpl/r/rpl_get_master_version_and_clock.result:
results are changed.
mysql-test/suite/rpl/t/rpl_get_master_version_and_clock.test:
rewriting the test from GET_LOCK()-based to DEBUG_SYNC-based;
limiting the test to run only with MIXED binlog-format as the test last
some 10 secs sensitively contributing to the total of tests run.
mysql-test/suite/rpl/t/rpl_show_slave_running.test:
rewriting the test from GET_LOCK()-based to DEBUG_SYNC-based.
sql/debug_sync.cc:
adding debug_sync_set_action() function as a facility to set up
a sync-action in the server sources code.
sql/debug_sync.h:
externalizing debug_sync_set_action().
sql/item_func.cc:
purging sources from DBUG_SYNC_POINT.
sql/mysql_priv.h:
purging sources from DBUG_SYNC_POINT.
sql/slave.cc:
rewriting failure simulations to base on DEBUG_SYNC rather than GET_LOCK()-based DBUG_SYNC_POINT.
sql/sql_repl.cc:
removing an orphan failure simulation line because no counterpart in tests existing.
Optimizer erroneously translated LEFT JOIN into INNER JOIN.
It leads to cutting rows with NULL right side. It happens
because Item_row uses not_null_tables() method form the
base(Item) class and does not calculate 'null tables'
properly. The fix is adding calculation of 'not null tables'
to Item_row.
mysql-test/r/join_outer.result:
test result
mysql-test/t/join_outer.test:
test case
sql/item_row.cc:
adding calculation of 'not null tables' to Item_row.
sql/item_row.h:
adding calculation of 'not null tables' to Item_row.
The crash happens because of discrepancy between values of
conts_tables and join->const_table_map(make_join_statisctics).
Calculation of conts_tables used condition with
HA_STATS_RECORDS_IS_EXACT flag check. Calculation of
join->const_table_map does not use this flag check.
In case of MERGE table without union with index
the table does not become const table and
thus join_read_const_table() is not called
for the table. join->const_table_map supposes
this table is const and later in make_join_select
this table is used for making&calculation const
condition. As table record buffer is not populated
it leads to crash.
The fix is adding a check if an engine supports
HA_STATS_RECORDS_IS_EXACT flag before updating
join->const_table_map.
mysql-test/r/merge.result:
test result
mysql-test/t/merge.test:
test case
sql/sql_select.cc:
adding a check if an engine supports
HA_STATS_RECORDS_IS_EXACT flag before updating
join->const_table_map.
for InnoDB
The class Field_bit_as_char stores the metadata for the
field incorrecly because bytes_in_rec and bit_len are set
to (field_length + 7 ) / 8 and 0 respectively, while
Field_bit has the correct values field_length / 8 and
field_length % 8.
Solved the problem by re-computing the values for the
metadata based on the field_length instead of using the
bytes_in_rec and bit_len variables.
To handle compatibility with old server, a table map
flag was added to indicate that the bit computation is
exact. If the flag is clear, the slave computes the
number of bytes required to store the bit field and
compares that instead, effectively allowing replication
*without conversion* from any field length that require
the same number of bytes to store.
mysql-test/suite/rpl/t/rpl_typeconv_innodb.test:
Adding test to check compatibility for bit field
replication when using InnoDB
sql/field.cc:
Extending compatible_field_size() with flags from
table map to allow fields to check master info.
sql/field.h:
Extending compatible_field_size() with flags from
table map to allow fields to check master info.
sql/log.cc:
Removing table map flags since they are not used
outside table map class.
sql/log_event.cc:
Removing flags parameter from table map constructor
since it is not used and does not have to be exposed.
sql/log_event.h:
Adding flag to denote that bit length for bit field type
is exact and not potentially rounded to even bytes.
sql/rpl_utility.cc:
Adding fields to table_def to store table map flags.
sql/rpl_utility.h:
Removing obsolete comment and adding flags to store
table map flags from master.
definition at engine
If a single ALTER TABLE contains both DROP INDEX and ADD INDEX using
the same index name (a.k.a. index modification) we need to disable
in-place alter table because we can't ask the storage engine to have
two copies of the index with the same name even temporarily (if we
first do the ADD INDEX and then DROP INDEX) and we can't modify
indexes that are needed by e.g. foreign keys if we first do
DROP INDEX and then ADD INDEX.
Fixed the problem by disabling in-place ALTER TABLE for these cases.
concurrent I_S query
There were two problem:
1) MYSQL_LOCK_IGNORE_FLUSH also ignored name locks
2) there was a race between abort_and_upgrade_locks and
alter_close_tables
(i.e. remove_table_from_cache and
close_data_files_and_morph_locks)
Which allowed the table to be opened with MYSQL_LOCK_IGNORE_FLUSH flag
resulting in renaming a partition that was already in use,
which could cause the table to be unusable.
Solution was to not allow IGNORE_FLUSH to skip waiting for
a named locked table.
And to not release the LOCK_open mutex between the
calls to remove_table_from_cache and
close_data_files_and_morph_locks by merging the functions
abort_and_upgrade_locks and alter_close_tables.
mysql-test/suite/parts/r/partition_debug_sync_innodb.result:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added test result
mysql-test/suite/parts/t/partition_debug_sync_innodb-master.opt:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added test option
mysql-test/suite/parts/t/partition_debug_sync_innodb.test:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added test file
sql/authors.h:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Time to be acknowledged :)
sql/ha_partition.cc:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added DEBUG_SYNC for deterministic testing
sql/mysql_priv.h:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Renamed function since merging alter_close_tables into
abort_and_upgrade_lock.
sql/sql_base.cc:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Changed MYSQL_LOCK_IGNORE_FLUSH to not ignore name locks
(open_placeholder).
Merged alter_close_tables into abort_and_upgrade_locks
(and added _and_close_table to the name)
to not release LOCK_open between remove_table_from_cache
and close_data_files_and_morph_locks.
Added DEBUG_SYNC for deterministic testing.
sql/sql_partition.cc:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Removed alter_close_tables, (merged it into
abort_and_upgrad_lock) so that LOCK_open never is released
between remove_table_from_cache and
close_data_files_and_morph_locks.
sql/sql_show.cc:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added DEBUG_SYNC for deterministic testing
NULL column for NULL
The optimization to read MIN() and MAX() values from an
index did not properly handle comparisons with NULL
values. Fixed by giving up the particular optimization step
if there are non-NULL safe comparisons with NULL values, as
the result is NULL anyway.
Also, Oracle copyright notice was added to all files.
Base Tables
The type inferrence of a view column caused the result to be
interpreted as the wrong type: DATE colums were interpreted
as TIME and TIME as DATETIME. This happened because view
columns are represented by Item_ref objects as opposed to
Item_field's. Item_ref had no method for retrieving a TIME
value and thus was forced to depend on the default
implementation for any expression, which caused the
expression to be evaluated as a string and then parsed into
a TIME/DATETIME value.
Fixed by letting Item_ref classes forward the request for a
TIME value to the referred Item - which is a field in this
case - this reads the TIME value directly without
conversion.
SunStudio
SunStudio compilers of late warn about methods that might hide
methods in base classes due to the use of overloading combined
with overriding. SunStudio also warns about variables defined
in local socpe or method arguments that have the same name as
a member attribute of the class.
This patch renames methods that might hide base class methods,
to make it easier both for humans and compilers to see what is
actually called. It also renames variables in local scope.
sql/field.cc:
Local scope variable or method argument same as class
attribute.
sql/item_cmpfunc.cc:
Local scope variable or method argument same as class
attribute.
sql/item_create.cc:
Renaming base class create() to create_func().
sql/item_create.h:
Renaming base class create() to create_func().
sql/protocol.cc:
Local scope variable or method argument same as class
attribute.
sql/sql_profile.cc:
Local scope variable or method argument same as class
attribute.
sql/sql_select.cc:
Local scope variable or method argument same as class
attribute.
sql/sql_yacc.yy:
Renaming base class create() to create_func().
storage/federated/ha_federated.cc:
Local scope variable or method argument same as class
attribute.
storage/myisammrg/ha_myisammrg.cc:
Local scope variable or method argument same as class
attribute.
(regression)
Problem was that partition pruning did not exclude the
last partition if the range was beyond it
(i.e. not using MAXVALUE)
Fix was to not include the last partition if the
partitioning function value was not within the partition
range.
mysql-test/r/partition_innodb.result:
Bug#51830: Incorrect partition pruning on range partition
(regression)
Updated result
mysql-test/r/partition_pruning.result:
Bug#51830: Incorrect partition pruning on range partition
(regression)
Updated result
mysql-test/t/partition_innodb.test:
Bug#51830: Incorrect partition pruning on range partition
(regression)
Added test for pruning in InnoDB, since it does not show
for MyISAM due to 'Impossible WHERE noticed after reading
const tables'.
mysql-test/t/partition_pruning.test:
Bug#51830: Incorrect partition pruning on range partition
(regression)
Added test
sql/sql_partition.cc:
Bug#51830: Incorrect partition pruning on range partition
(regression)
Also increase the partition id if not inside the last partition
(and no MAXVALUE is defined).
Added comments and DBUG_ASSERT.
SET autocommit=1 while XA transaction is active may
cause various side effects, including memory corruption
and server crash.
The problem is that SET autocommit=1 and further queries
attempt to commit local transaction, whereas XA transaction
is still active.
As local and XA transactions are mutually exclusive, this
patch forbids enabling autocommit mode while XA transaction
is active.
mysql-test/r/xa.result:
A test case for BUG#51342.
mysql-test/t/xa.test:
A test case for BUG#51342.
sql/set_var.cc:
Forbid enabling autocommit mode while XA transaction is
active.
MySQL uses two source layouts when building : the bzr
layout and the source package layout.
The previous fix for bug 35250 contained 1 change that is
valid for both modes and a number of changes that are valid
only for the bzr source layout.
The important thing was to fix the source package layout.
And for this the change in configure.in was sufficient.
It's not trivial (and not requested by this bug) to support
VPATH builds from the bzr trees.
This is why the other changes are reverted and the change to
fix the VPATH build for source distributions is left intact.
The problem was that killing a query during the optimization
phase of a subselect would lead to crashes. The root of the
problem is that the subselect execution engine ignores failures
(eg: killed) during the optimization phase (JOIN::optimize),
leading to a crash once the subquery is executed due to
partially initialized structures (in this case a join tab).
The optimal solution would be to cleanup certain optimizer
structures if the optimization phase fails, but currently
there is no infrastructure to properly to track and cleanup
the structures. To workaround the whole problem one somewhat
good solution is to avoid executing a subselect if the query
has been killed. Cutting short any problems caused by failures
during the optimization phase.
sql/item_subselect.cc:
Do not execute a subselect if the session or query has been killed.
The problem was that UNINSTALL PLUGIN wasn't performing privilege
checks before removing a plugin. Any user (including users without
any kind of privileges) could uninstall any plugin.
The solution is to verify if the user has the DELETE privilege for
the mysql.plugin table before uninstalling a plugin.
mysql-test/r/plugin_not_embedded.result:
Add test case result for Bug#51770.
mysql-test/t/plugin_not_embedded-master.opt:
Add example plugin path.
mysql-test/t/plugin_not_embedded.test:
Add test case for Bug#51770.
Skip embedded as test relies on privileges checks.
The problem is that Item_direct_view_ref which is inherited
from Item_ident updates orig_table_name and table_name with
the same values. The fix is introduction of new constructor
into Item_ident and up which updates orig_table_name and
table_name separately.
mysql-test/r/metadata.result:
test case
mysql-test/t/metadata.test:
test case
sql/item.cc:
new constructor which updates
orig_table_name and table_name
separately.
sql/item.h:
new constructor which updates
orig_table_name and table_name
separately.
sql/table.cc:
used new constructor
the fill_schema_processlist function accesses THD::query() without proper protection
so the parallel thread killing can lead to access to the freed meemory.
per-file comments:
sql/sql_load.cc
Bug#51377 Crash in information_schema / processlist on concurrent DDL workload
the THD::set_query_inner() call needs to be protected.
But here we don't need to change the original thd->query() at all.
sql/sql_show.cc
Bug#51377 Crash in information_schema / processlist on concurrent DDL workload
protect the THD::query() access with the THD::LOCK_thd_data mutex.
The problem is that not all column names retrieved from a SELECT
statement can be used as view column names due to length and format
restrictions. The server failed to properly check the conformity
of those automatically generated column names before storing the
final view definition on disk.
Since columns retrieved from a SELECT statement can be anything
ranging from functions to constants values of any format and length,
the solution is to rewrite to a pre-defined format any names that
are not acceptable as a view column name.
The name is rewritten to "Name_exp_%u" where %u translates to the
position of the column. To avoid this conversion scheme, define
explict names for the view columns via the column_list clause.
Also, aliases are now only generated for top level statements.
mysql-test/include/view_alias.inc:
Add test case for Bug#40277
mysql-test/r/compare.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/group_by.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/ps.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/subselect.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/subselect3.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/type_datetime.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/union.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/view.result:
Add test case result for Bug#40277
mysql-test/r/view_alias.result:
Add test case result for Bug#40277
mysql-test/t/view_alias.test:
Add test case for Bug#40277
sql/sql_view.cc:
Check if auto generated column names are conforming. Also, the
make_unique_view_field_name function is not used as it uses the
original name to construct a new one, which does not work if the
name is invalid.
The problem was that bits of the destructive equality propagation
optimization weren't being undone after the execution of a stored
program. Modifications to the parse tree that are based on transient
properties must be undone to enable the re-execution of stored
programs.
The solution is to cleanup any references to predicates generated
by the equality propagation during the execution of a stored program.
mysql-test/r/trigger.result:
Add test case result for Bug#51650.
mysql-test/t/trigger.test:
Add test case for Bug#51650.
sql/item.cc:
Remove reference to a equality predicate.
auto_increment on duplicate entry
The bug was that when INSERT_ID was used and the storage
engine was told to release any reserved but not used
auto_increment values, it set the highest auto_increment
value to INSERT_ID.
The fix was to check if the auto_increment value was forced
by user (INSERT_ID) or by slave-thread, i.e. not auto-
generated. So that it is only allowed to release generated
values.
mysql-test/r/partition_error.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
updated result
mysql-test/suite/parts/inc/partition_auto_increment.inc:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added test
mysql-test/suite/parts/r/partition_auto_increment_archive.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that archive does only allow increasing
auto_increment values
mysql-test/suite/parts/r/partition_auto_increment_blackhole.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that blackhole accepts all inserts :)
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that innodb rolls back inserts on error,
but keeps the auto_increment value.
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that memory and myisam inserts all rows
before the error.
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that memory and myisam inserts all rows
before the error.
mysql-test/suite/parts/r/partition_auto_increment_ndb.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that NDB does not seem to handle
INSERT_ID as other engines. (Martin will look into it).
mysql-test/t/partition_error.test:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added test
sql/ha_partition.cc:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
If the next_insert_id comes from non generated (i.e
forced by INSERT_ID or slave-thread) then we cannot
lower the reserved auto_increment value, since it have
not reserved any values.
consider clustered primary keys
Choosing a shortest index for the covering index scan,
the optimizer ignored the fact, that the clustered primary
key read involves whole table data.
The find_shortest_key function has been modified to
take into account that fact that a clustered PK has a
longest key of possible covering indices.
mysql-test/r/innodb_mysql.result:
Test case for bug #39653.
mysql-test/t/innodb_mysql.test:
Test case for bug #39653.
sql/sql_select.cc:
Bug #39653: find_shortest_key in sql_select.cc does not
consider clustered primary keys
The find_shortest_key function has been modified to
take into account that fact that a clustered PK has a
longest key of possible covering indices.
There was no check for foreign keys when altering partitioned
tables.
Added check for FK when altering partitioned tables.
mysql-test/r/partition_innodb.result:
Bug#50104: Partitioned table with just 1 partion works with fk
Updated test result
mysql-test/t/partition_innodb.test:
Bug#50104: Partitioned table with just 1 partion works with fk
Added test for adding FK on partitioned tables (both 1 and 2
partitions)
sql/sql_partition.cc:
Bug#50104: Partitioned table with just 1 partion works with fk
Disabled adding foreign key when altering a partitioned table.
Problem was block_size on partitioned tables was not set,
resulting in keys_per_block was not correct which affects
the cost calculation for read time of indexes (including
cost for group min/max).Which resulted in a bad optimizer
decision.
Fixed by setting stats.block_size correctly.
mysql-test/r/partition_range.result:
Bug#48229: group by performance issue of partitioned table
Added result
mysql-test/t/partition_range.test:
Bug#48229: group by performance issue of partitioned table
Added test
sql/ha_partition.cc:
Bug#48229: group by performance issue of partitioned table
Added missing assignment of stats.block_size.
mode
When the master was executing in sql_mode='traditional' (which
implies that really_abort_on_warning returns TRUE - because of
MODE_STRICT_ALL_TABLES), the error code (ER_DUP_ENTRY in the
reported case) was not being set in the
Query_log_event. Therefore, even if a failure was to be expected
when replaying the statement on the slave, a failure would occur,
because the Query_log_event was not transporting the expected
error code, but 0 instead.
This was because when the master was getting the error code to
set it in the Query_log_event, the executing thread would be
assumed to have been killed:
THD::killed==THD::KILL_BAD_DATA. This would make the error code
fetch routine not to check thd->main_da.sql_errno(), but instead
the thd->killed value. What's more, is that the server would
thd->killed value if thd->killed == THD::KILL_BAD_DATA and return
0 instead. So this is a double inconsistency, as the we should
not even check thd->killed but rather thd->main_da.sql_errno().
We fix this by extending the condition used to choose whether to
check the thd->main_da.sql_errno() or thd->killed, so that it
takes into consideration the case when:
thd->killed==THD::KILL_BAD_DATA.
+ failing statements
Implicit DROP event for temporary table is not getting
LOG_EVENT_THREAD_SPECIFIC_F flag, because, in the previous
executed statement in the same thread, which might even be a
failed statement, the thread_specific_used flag is set to
FALSE (in mysql_reset_thd_for_next_command) and not set to TRUE
before connection is shutdown. This means that implicit DROP
event will take the FALSE value from thread_specific_used and
will not set LOG_EVENT_THREAD_SPECIFIC_F in the event header. As
a consequence, mysqlbinlog will not print the pseudo_thread_id
from the DROP event, because one of the requirements for the
printout is that this flag is set to TRUE.
We fix this by setting thread_specific_used whenever we are
binlogging a DROP in close_temporary_tables, and resetting it to
its previous value afterward.
