The problem was in incorrect handling of predicates involving
NULL as a constant value by the range optimizer.
For example, when creating a SEL_ARG node from a condition of
the form "field < const" (which would normally result in the
"NULL < field < const" SEL_ARG), the special case when "const"
is NULL was not taken into account, so "NULL < field < NULL"
was produced for the "field < NULL" condition.
As a result, SEL_ARG structures of this form could not be
further optimized which in turn could lead to incorrectly
constructed SEL_ARG trees. In particular, code assuming SEL_ARG
structures to always form a sequence of ordered disjoint
intervals could enter an infinite loop under some
circumstances.
Fixed by changing get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
mysql-test/r/partition_pruning.result:
Fixed a broken test case.
mysql-test/r/range.result:
Added a test case for bug #47123.
mysql-test/r/subselect.result:
Fixed a broken test cases.
mysql-test/t/range.test:
Added a test case for bug #47123.
sql/opt_range.cc:
Fixed get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
view that has Group By
When SELECT'ing from a view that mentions another,
materialized, view, access was being denied. The issue was
resolved by lifting a special case which avoided such access
checking in check_single_table_access. In the past, this was
necessary since if such a check were performed, the error
message would be downgraded to a warning in the case of SHOW
CREATE VIEW. The downgrading of errors was meant to handle
only that scenario, but could not distinguish the two as it
read only the error messages.
The special case was needed in the fix of bug no 36086.
Before that, views were confused with derived tables.
After bug no 35996 was fixed, the manipulation of errors
during SHOW CREATE VIEW execution is not dependent on the
actual error messages in the queue, it rather looks at the
actual cause of the error and takes appropriate
action. Hence the aforementioned special case is now
superfluous and the bug is fixed.
mysql-test/r/view_grant.result:
Bug#46019: Test result.
mysql-test/t/view_grant.test:
Bug#46019: Test case.
sql/sql_parse.cc:
Bug#46019: fix.
Implemented the server infrastructure for the fix:
1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of
thd_query()
2. Did some encapsulation in THD : aggregated thd_query and
thd_query_length into a LEX_STRING and made accessor and mutator
methods for easy code updating.
3. Updated the server code to use the new methods where applicable.
Temporary tables may set join->group to 0 even though there is
grouping. Also need to test if sum_func_count>0 when JOIN::exec()
decides whether to present results in a grouped manner.
sql/sql_select.cc:
Temporary tables may set join->group to 0 even though there is
grouping. Also need to test if sum_func_count>0 when JOIN::exec()
decides whether to present results in a grouped manner.
columns without where/group
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.
mysql-test/r/func_group.result:
Add test for BUG#47280
mysql-test/t/func_group.test:
Add test for BUG#47280
sql/opt_sum.cc:
Improve comment for opt_sum_query()
sql/sql_class.h:
Add comment for variables in TMP_TABLE_PARAM
sql/sql_select.cc:
Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries (JOIN::optimize) and choice of end_select method (JOIN::execute)
sql/sql_select.h:
Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.
The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
id stored inside the events of the BINLOG statement rather than the id of the running
server.
Fix by rearranging code a bit so that only relevant parts of the code are executed by
the BINLOG statement, and the server_id of the server executing the statements will
not be overrided by the server_id stored in the 'format description BINLOG statement'.
mysql-test/extra/binlog_tests/binlog.test:
Added test to verify if the server_id stored in the 'format
description BINLOG statement' will override the server_id
of the server executing the statements.
mysql-test/suite/binlog/r/binlog_row_binlog.result:
Test result for bug#46640
mysql-test/suite/binlog/r/binlog_stm_binlog.result:
Test result for bug#46640
sql/log_event.cc:
Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
makes more sense, and is needed as update_pos() is no longer called when executing
BINLOG statements.
Moved setting of rli->relay_log.description_event_for_exec from
Format_description_log_event::do_update_pos() to
Format_description_log_event::do_apply_event()
sql/log_event_old.cc:
Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
makes more sense, and is needed as update_pos() is no longer called when executing
BINLOG statements.
sql/slave.cc:
The skip flag is no longer needed, as the code path for BINLOG statement has been
cleaned up.
sql/sql_binlog.cc:
Don't invoke the update_pos() code path for the BINLOG statement, as it contains code
that is redundant and/or harmful (especially setting thd->server_id).
The problem was in incorrect handling of predicates involving
NULL as a constant value by the range optimizer.
For example, when creating a SEL_ARG node from a condition of
the form "field < const" (which would normally result in the
"NULL < field < const" SEL_ARG), the special case when "const"
is NULL was not taken into account, so "NULL < field < NULL"
was produced for the "field < NULL" condition.
As a result, SEL_ARG structures of this form could not be
further optimized which in turn could lead to incorrectly
constructed SEL_ARG trees. In particular, code assuming SEL_ARG
structures to always form a sequence of ordered disjoint
intervals could enter an infinite loop under some
circumstances.
Fixed by changing get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
mysql-test/r/range.result:
Added a test case for bug #47123.
mysql-test/t/range.test:
Added a test case for bug #47123.
sql/opt_range.cc:
Fixed get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
Problem: using null microsecond part (e.g. "YYYY-MM-DD HH:MM:SS.0000")
in a WHERE condition may lead to wrong results due to improper
DATETIMEs comparison in some cases.
Fix: as we compare DATETIMEs as strings we must trim trailing 0's
in such cases.
mysql-test/r/innodb_mysql.result:
Fix for bug#47963: Wrong results when index is used
- test result.
mysql-test/t/innodb_mysql.test:
Fix for bug#47963: Wrong results when index is used
- test case.
sql/item.cc:
Fix for bug#47963: Wrong results when index is used
- comparing DATETIMEs trim trailing 0's in the
microsecond part.
removed if server_id changes
When MySQL crashes (or a snapshot is taken which simulates
a crash), then it is possible that internal XA
transactions (used to sync the binary log and InnoDB)
can be left in a PREPARED state, whereas they should be
rolled back. This is done when the server_id changes
before the restart occurs.
This patch releases he restriction that the server_id
should be consistent if the XID is to be considerred
valid. The rollback phase should then be able to
clean up all pending XA transactions.
We set up DATE and TIMESTAMP differently in field-creation than we
did in field-MD creation (for CREATE). Admirably, ALTER TABLE
detected this and didn't damage any data, but it did initiate a
full copy/conversion, which we don't really need to do.
Now we describe Field and Create_field the same for those types.
As a result, ALTER TABLE that only changes meta-data (like a
field's name) no longer forces a data-copy when there needn't
be one.
mysql-test/r/alter_table.result:
0 rows should be affected when a meta-data change is enough ALTER TABLE.
mysql-test/t/alter_table.test:
add test-case: show that we don't do a full data-copy on ALTER TABLE
when we don't need to.
sql/field.cc:
Remove Field_str::compare_str_field_flags() (now in Field/Create_field as
field_flags_are_binary().
Correct some field-lengths!
sql/field.h:
Clean-up: use defined constants rather than numeric literals for certain
field-lengths.
Add enquiry-functions binaryp() to classes Field and Create_field.
This replaces field.cc's Field_str::compare_str_field_flags().
covering index
When two range predicates were combined under an OR
predicate, the algorithm tried to merge overlapping ranges
into one. But the case when a range overlapped several other
ranges was not handled. This lead to
1) ranges overlapping, which gave repeated results and
2) a range that overlapped several other ranges was cut off.
Fixed by
1) Making sure that a range got an upper bound equal to the
next range with a greater minimum.
2) Removing a continue statement
mysql-test/r/group_min_max.result:
Bug#42846: Changed query plans
mysql-test/r/range.result:
Bug#42846: Test result.
mysql-test/t/range.test:
Bug#42846: Test case.
sql/opt_range.cc:
Bug#42846: The fix.
Part1: Previously, both endpoints from key2 were copied,
which is not safe. Since ranges are processed in ascending
order of minimum endpoints, it is safe to copy the minimum
endpoint from key2 but not the maximum. The maximum may only
be copied if there is no other range or the other range's
minimum is greater than key2's maximum.
backport for bug#44059 from mysql-pe to mysql-5.1-bugteam
Using the partition with most rows instead of first partition
to estimate the cardinality of indexes.
mysql-test/r/partition.result:
Bug#44059: Incorrect cardinality of indexes on a partitioned table
Added test result
mysql-test/t/partition.test:
Bug#44059: Incorrect cardinality of indexes on a partitioned table
Added test case
sql/ha_partition.cc:
Bug#44059: Incorrect cardinality of indexes on a partitioned table
Checking which partition that has the most rows, and using that
partition for HA_STATUS_CONST instead of first partition
is reached
Problem was bad error handling, leaving some new temporary
partitions locked and initialized and some not yet initialized
and locked, leading to a crash when trying to unlock the not
yet initialized and locked partitions
Solution was to unlock the already locked partitions, and not
include any of the new temporary partitions in later unlocks
mysql-test/r/partition_open_files_limit.result:
Bug#46922: crash when adding partitions and open_files_limit
is reached
New test result
mysql-test/t/partition_open_files_limit-master.opt:
Bug#46922: crash when adding partitions and open_files_limit
is reached
New test opt-file for testing when open_files_limit is reached
mysql-test/t/partition_open_files_limit.test:
Bug#46922: crash when adding partitions and open_files_limit
is reached
New test case testing when open_files_limit is reached
sql/ha_partition.cc:
Bug#46922: crash when adding partitions and open_files_limit
is reached
When cleaning up the partitions already locked need to be unlocked,
and not be unlocked/closed after cleaning up.
can lead to bad memory access
Problem: Field_bit is the only field which returns INT_RESULT
and doesn't have unsigned flag. As it's not a descendant of the
Field_num, so using ((Field_num *) field_bit)->unsigned_flag may lead
to unpredictable results.
Fix: check the field type before casting.
mysql-test/r/type_bit.result:
Fix for bug #42803: Field_bit does not have unsigned_flag field,
can lead to bad memory access
- test result.
mysql-test/t/type_bit.test:
Fix for bug #42803: Field_bit does not have unsigned_flag field,
can lead to bad memory access
- test case.
sql/opt_range.cc:
Fix for bug #42803: Field_bit does not have unsigned_flag field,
can lead to bad memory access
- don't cast to (Field_num *) Field_bit, as it's not a Field_num
descendant and is always unsigned by nature.
buffering is used
FORCE INDEX FOR ORDER BY now prevents the optimizer from
using join buffering. As a result the optimizer can use
indexed access on the first table and doesn't need to
sort the complete resultset at the end of the statement.
Let
- T be a transactional table and N non-transactional table.
- B be begin, C commit and R rollback.
- N be a statement that accesses and changes only N-tables.
- T be a statement that accesses and changes only T-tables.
In RBR, changes to N-tables that happen early in a transaction are not immediately flushed
upon committing a statement. This behavior may, however, break consistency in the presence
of concurrency since changes done to N-tables become immediately visible to other
connections. To fix this problem, we do the following:
. B N N T C would log - B N C B N C B T C.
. B N N T R would log - B N C B N C B T R.
Note that we are not preserving history from the master as we are introducing a commit that
never happened. However, this seems to be more acceptable than the possibility of breaking
consistency in the presence of concurrency.
Let
- T be a transactional table and N non-transactional table.
- B be begin, C commit and R rollback.
- M be a mixed statement, i.e. a statement that updates both T and N.
- M* be a mixed statement that fails while updating either T or N.
This patch restore the behavior presented in 5.1.37 for rows either produced in
the RBR or MIXED modes, when a M* statement that happened early in a transaction
had their changes written to the binary log outside the boundaries of the
transaction and wrapped in a BEGIN/ROLLBACK. This was done to keep the slave
consistent with with the master as the rollback would keep the changes on N and
undo them on T. In particular, we do what follows:
. B M* T C would log - B M* R B T C.
Note that, we are not preserving history from the master as we are introducing a
rollback that never happened. However, this seems to be more acceptable than
making the slave diverge. We do not fix the following case:
. B T M* C would log B T M* C.
The slave will diverge as the changes on T tables that originated from the M
statement are rolled back on the master but not on the slave. Unfortunately, we
cannot simply rollback the transaction as this would undo any uncommitted
changes on T tables.
SBR is not considered in this patch because a failing statement is written to
the binary along with the error code and a slave executes and then rolls back
the statement when it has an associated error code, thus undoing the effects
on T. In RBR and MBR, a full-fledged fix will be pushed after the WL 2687.
SELECT ... WHERE ... IN (NULL, ...) does full table scan,
even if the same query without the NULL uses efficient range scan.
The bugfix for the bug 18360 introduced an optimization:
if
1) all right-hand arguments of the IN function are constants
2) result types of all right argument items are compatible
enough to use the same single comparison function to
compare all of them to the left argument,
then
we can convert the right-hand list of constant items to an array
of equally-typed constant values for the further
QUICK index access etc. (see Item_func_in::fix_length_and_dec()).
The Item_null constant item objects have STRING_RESULT
result types, so, as far as Item_func_in::fix_length_and_dec()
is aware of NULLs in the right list, this improvement efficiently
optimizes IN function calls with a mixed right list of NULLs and
string constants. However, the optimization doesn't affect mixed
lists of NULLs and integers, floats etc., because there is no
unique common comparator.
New optimization has been added to ignore the result type
of NULL constants in the static analysis of mixed right-hand lists.
This is safe, because at the execution phase we care about
presence of NULLs anyway.
1. The collect_cmp_types() function has been modified to optionally
ignore NULL constants in the item list.
2. NULL-skipping code of the Item_func_in::fix_length_and_dec()
function has been modified to work not only with in_string
vectors but with in_vectors of other types.
mysql-test/r/func_in.result:
Added test case for the bug #44139.
mysql-test/t/func_in.test:
Added test case for the bug #44139.
sql/item_cmpfunc.cc:
Bug #44139: Table scan when NULL appears in IN clause
1. The collect_cmp_types() function has been modified to optionally
ignore NULL constants in the item list.
2. NULL-skipping code of the Item_func_in::fix_length_and_dec()
function has been modified to work not only with in_string
vectors but with in_vectors of other types.
The problem is that there is only one autoinc value associated with
the query when binlogging. If more than one autoinc values are used
in the query, the autoinc values after the first one can be inserted
wrongly on slave. So these autoinc values can become inconsistent on
master and slave.
The problem is resolved by marking all the statements that invoke
a trigger or call a function that updated autoinc fields as unsafe,
and will switch to row-format in Mixed mode. Actually, the statement
is safe if just one autoinc value is used in sub-statement, but it's
impossible to check how many autoinc values are used in sub-statement.)
mysql-test/suite/rpl/r/rpl_auto_increment_update_failure.result:
Test result for bug#45677
mysql-test/suite/rpl/t/rpl_auto_increment_update_failure.test:
Added test to verify the following two properties:
P1) insert/update in an autoinc column causes statement to
be logged in row format if binlog_format=mixed
P2) if binlog_format=mixed, and a trigger or function contains
two or more inserts/updates in a table that has an autoinc
column, then the slave should not go out of sync, even if
there are concurrent transactions.
sql/sql_base.cc:
Added function 'has_write_table_with_auto_increment' to check
if one (or more) write tables have auto_increment columns.
Removed function 'has_two_write_locked_tables_with_auto_increment',
because the function is included in function
'has_write_table_with_auto_increment'.
On Mac OS X or Windows, sending a SIGHUP to the server or a
asynchronous flush (triggered by flush_time), would cause the
server to crash.
The problem was that a hook used to detach client API handles
wasn't prepared to handle cases where the thread does not have
a associated session.
The solution is to verify whether the thread has a associated
session before trying to detach a handle.
mysql-test/r/federated_debug.result:
Add test case result for Bug#47525
mysql-test/t/federated_debug-master.opt:
Debug point.
mysql-test/t/federated_debug.test:
Add test case for Bug#47525
sql/slave.cc:
Check whether a the thread has a associated session.
sql/sql_parse.cc:
Add debug code to simulate a reload without thread session.
'flush tables' crashes
The server crashes when 'show procedure status' and 'flush tables' are
run concurrently.
This is caused by the way mysql.proc table is added twice to the list
of table to lock although the requirements on the current locking API
assumes differently.
No test case is submitted because of the nature of the crash which is
currently difficult to reproduce in a deterministic way.
This is a backport from 5.1
myisam/mi_dbug.c:
* check_table_is_closed is only used in EXTRA_DEBUG mode but since it is
iterating over myisam shared data it still needs to be protected by an
appropriate mutex.
sql/sql_yacc.yy:
* Since the I_S mechanism is already handling the open and close of
mysql.proc there is no need for the method sp_add_to_query_tables.
Backport from 6.0 to 5.1.
Only those sync points are included, which are used in debug_sync.test.
The Debug Sync Facility allows to place synchronization points
in the code:
open_tables(...)
DEBUG_SYNC(thd, "after_open_tables");
lock_tables(...)
When activated, a sync point can
- Send a signal and/or
- Wait for a signal
Nomenclature:
- signal: A value of a global variable that persists
until overwritten by a new signal. The global
variable can also be seen as a "signal post"
or "flag mast". Then the signal is what is
attached to the "signal post" or "flag mast".
- send a signal: Assign the value (the signal) to the global
variable ("set a flag") and broadcast a
global condition to wake those waiting for
a signal.
- wait for a signal: Loop over waiting for the global condition until
the global value matches the wait-for signal.
Please find more information in the top comment in debug_sync.cc
or in the worklog entry.
.bzrignore:
WL#4259 - Debug Sync Facility
Added the symbolic link libmysqld/debug_sync.cc.
CMakeLists.txt:
WL#4259 - Debug Sync Facility
Added definition for ENABLED_DEBUG_SYNC.
configure.in:
WL#4259 - Debug Sync Facility
Added definition for ENABLED_DEBUG_SYNC.
include/my_sys.h:
WL#4259 - Debug Sync Facility
Added definition for the DEBUG_SYNC_C macro.
libmysqld/CMakeLists.txt:
WL#4259 - Debug Sync Facility
Added sql/debug_sync.cc.
libmysqld/Makefile.am:
WL#4259 - Debug Sync Facility
Added sql/debug_sync.cc.
mysql-test/include/have_debug_sync.inc:
WL#4259 - Debug Sync Facility
New include file.
mysql-test/mysql-test-run.pl:
WL#4259 - Debug Sync Facility
Added option --debug_sync_timeout.
mysql-test/r/debug_sync.result:
WL#4259 - Debug Sync Facility
New test result.
mysql-test/r/have_debug_sync.require:
WL#4259 - Debug Sync Facility
New require file.
mysql-test/t/debug_sync.test:
WL#4259 - Debug Sync Facility
New test file.
mysys/my_static.c:
WL#4259 - Debug Sync Facility
Added definition for debug_sync_C_callback_ptr.
mysys/thr_lock.c:
WL#4259 - Debug Sync Facility
Added sync point "wait_for_lock".
sql/CMakeLists.txt:
WL#4259 - Debug Sync Facility
Added debug_sync.cc and debug_sync.h.
sql/Makefile.am:
WL#4259 - Debug Sync Facility
Added debug_sync.cc and debug_sync.h.
sql/debug_sync.cc:
WL#4259 - Debug Sync Facility
New source file.
sql/debug_sync.h:
WL#4259 - Debug Sync Facility
New header file.
sql/mysqld.cc:
WL#4259 - Debug Sync Facility
Added opt_debug_sync_timeout.
Added calls to debug_sync_init() and debug_sync_end().
Fixed a purecov comment (unrelated).
sql/set_var.cc:
WL#4259 - Debug Sync Facility
Added server variable "debug_sync".
sql/set_var.h:
WL#4259 - Debug Sync Facility
Added declaration for server variable "debug_sync".
sql/share/errmsg.txt:
WL#4259 - Debug Sync Facility
Added error messages ER_DEBUG_SYNC_TIMEOUT and ER_DEBUG_SYNC_HIT_LIMIT.
sql/sql_base.cc:
WL#4259 - Debug Sync Facility
Added sync points "after_flush_unlock" and "before_lock_tables_takes_lock".
sql/sql_class.cc:
WL#4259 - Debug Sync Facility
Added initialization for debug_sync_control to THD::THD.
Added calls to debug_sync_init_thread() and debug_sync_end_thread().
sql/sql_class.h:
WL#4259 - Debug Sync Facility
Added element debug_sync_control to THD.
storage/myisam/myisamchk.c:
Fixed a typo in an error message string (unrelated).
replication
MySQL server uses wrong lock type (always TL_READ instead of
TL_READ_NO_INSERT when appropriate) for tables used in
subqueries of UPDATE statement. This leads in some cases to
a broken replication as statements are written in the wrong
order to the binlog.
sql/sql_yacc.yy:
* Set lock_option to either TL_READ_NO_INSERT or
TL_READ for any sub-SELECT following UPDATE.
* Changed line adjusted for parser identation
rules; code begins at column 13.
The problem was that appending values to the end of an existing
ENUM or SET column was being treated as table data modification,
preventing a immediately (fast) table alteration that occurs when
only table metadata is being modified.
The cause was twofold: adding a enumeration or set members to the
end of the list of valid member values was not being considered
a "compatible" table alteration, and for SET columns, the check
was being done upon the max display length and not the underlying
(pack) length of the field.
The solution is to augment the function that checks wether two ENUM
or SET fields are compatible -- by comparing the pack lengths and
performing a limited comparison of the member values.
mysql-test/r/alter_table.result:
Add test case result for Bug#45567
mysql-test/t/alter_table.test:
Add test case for Bug#45567
sql/field.cc:
Check whether two fields can be considered 'equal' for table
alteration purposes. Fields are equal if they retain the same
pack length and if new members are added to the end of the list.
sql/field.h:
Add comment and remove method.
The bug is not related to MERGE table or TRIGGER. More correct description
would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
On PREPARE stage(see test case) we call mark_common_columns() func which
creates ON condition for NATURAL JOIN and sets appropriate
table read_set bitmaps for fields which are used in ON condition.
On EXECUTE stage mark_common_columns() is not called, we set
necessary read_set bitmaps in setup_conds(). But 'B.f1' field
is already processed and related item alredy fixed before
setup_conds() as updated field and setup_conds can not set
read_set bitmap because of that.
The fix is to set read_set bitmap for appropriate table field even
if Item_direct_view_ref item which represents a refernce to this field
is fixed.
mysql-test/r/join.result:
test result
mysql-test/t/join.test:
test case
sql/item.cc:
The bug is not related to MERGE table or TRIGGER. More correct description
would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
On PREPARE stage(see test case) we call mark_common_columns() func which
creates ON condition for NATURAL JOIN and sets appropriate
table read_set bitmaps for fields which are used in ON condition.
On EXECUTE stage mark_common_columns() is not called, we set
necessary read_set bitmaps in setup_conds(). But 'B.f1' field
is already processed and related item alredy fixed before
setup_conds() as updated field and setup_conds can not set
read_set bitmap because of that.
The fix is to set read_set bitmap for appropriate table field even
if Item_direct_view_ref item which represents a refernce to this field
is fixed.
"load data" statements were written to the binlog as a mix of the original statement
and bits recreated from parse-info. This relied on implementation details and broke
with IGNORE_SPACES and versioned comments.
We now completely resynthesize the query for LOAD DATA for binlog (which among other
things normalizes them somewhat with regard to case, spaces, etc.).
We have already parsed the query properly, so we make use of that rather
than mix-and-match string literals and parsed items.
This should make us safe with regard to versioned comments, even those
spanning multiple tokens. Also no longer affected by IGNORE_SPACES.
mysql-test/r/mysqlbinlog.result:
LOAD DATA INFILE normalized
mysql-test/suite/binlog/r/binlog_killed_simulate.result:
LOAD DATA INFILE normalized
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
LOAD DATA INFILE normalized
mysql-test/suite/binlog/r/binlog_stm_blackhole.result:
LOAD DATA INFILE normalized
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
LOAD DATA INFILE normalized
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
LOAD DATA INFILE normalized
mysql-test/suite/rpl/r/rpl_loaddata.result:
LOAD DATA INFILE normalized
mysql-test/suite/rpl/r/rpl_loaddata_fatal.result:
LOAD DATA INFILE normalized; offsets adjusted to reflect that
mysql-test/suite/rpl/r/rpl_loaddata_map.result:
LOAD DATA INFILE normalized
mysql-test/suite/rpl/r/rpl_loaddatalocal.result:
test for #43746 - trying to break LOAD DATA part of parser
mysql-test/suite/rpl/r/rpl_stm_log.result:
LOAD DATA INFILE normalized
mysql-test/suite/rpl/t/rpl_loaddatalocal.test:
try to break the LOAD DATA part of the parser (test for #43746)
mysql-test/t/mysqlbinlog.test:
LOAD DATA INFILE normalized; adjust offsets to reflect that
sql/log_event.cc:
clean up Load_log_event::print_query and friends so they don't print
excess spaces. add support for printing charset names to print_query.
sql/log_event.h:
We already have three places where we synthesize LOAD DATA queries.
Better use one of those!
sql/sql_lex.h:
When binlogging LOAD DATA statements, we make up the statement to
be logged (from the parse-info, rather than substrings of the
original query) now. Consequently, we no longer need (string-)
pointers into the original query.
sql/sql_load.cc:
Completely rewrote write_execute_load_query_log_event() to synthesize the
LOAD DATA statement wholesale, rather than piece it together from
synthesized bits and literal excerpts from the original query. This
will not only give us a nice, normalized statement (all uppercase,
no excess spaces, etc.), it will also handle comments, including
versioned comments right, which is certainly more than we can say
about the previous incarnation.
sql/sql_yacc.yy:
We're no longer assembling LOAD DATA statements from bodyparts of the
original query, so some bookkeeping in the parser can go.
view definition
During SHOW CREATE VIEW there is no reason to 'anonymize'
errors that name objects that a user does not have access
to. Moreover it was inconsistently implemented. For example
base tables being referenced from a view appear to be ok,
but not views. The manual on the other hand is clear: If a
user has the privileges SELECT and SHOW VIEW, the view
definition is available to that user, period. The fix
changes the behavior to support the manual.
mysql-test/r/information_schema_db.result:
Bug#35996: Changed warnings.
mysql-test/r/view_grant.result:
Bug#35996: Changed warnings, test result.
mysql-test/t/information_schema_db.test:
Bug#35996: Changed test case to reflect new behavior.
mysql-test/t/view_grant.test:
Bug#35996: Test case.
sql/sql_acl.cc:
Bug#35996: Code no longer necessary, we may as well exempt
SHOW CREATE VIEW from this check.
sql/sql_show.cc:
Bug#35996: The fix: An Internal_error_handler that hides
most errors raised by access checking as they are not
relevant to SHOW CREATE VIEW.
sql/table.cc:
Bug#35996: Restricting this hack to act only when there is
no Internal_error_handler.
trigger, merge table
The problem with break statements is that they have very
local effects. Hence a break statement within the inner loop
of a nested-loops join caused execution to proceed to the
next table even though a serious error occurred. The problem
was fixed by breaking out the inner loop into its own
method. The change empowers all errors to terminate the
execution.
The errors that will now halt multi-DELETE execution
altogether are
- triggers returning errors
- handler errors
- server being killed
mysql-test/r/delete.result:
Bug#46958: Test result.
mysql-test/t/delete.test:
Bug#46958: Test case.
sql/sql_class.h:
Bug#46958: New method declaration.
sql/sql_delete.cc:
Bug#46958: New method implementation.
In RBR, 'DROP TEMPORARY TABLE IF EXISTS...' statement is binlogged when the table
does not exist.
In fact, 'DROP TEMPORARY TABLE ...' statement should never be binlogged in RBR
no matter if the table exists or not.
This patch addresses this by checking whether we are dropping a
temporary table or not, when building the custom drop statement.
HA_ERR_WRONG_INDEX
In RBR, disabling keys on slave table will break replication when
updating or deleting a record. When the slave thread tries to
find the row, by searching in the storage engine, it checks
whether the table has a key or not. If it has one, then the slave
thread uses it to search the record.
Nonetheless, the slave only checks whether the key exists or not,
it does not verify if it is active. Should the key be
disabled (eg, DBA has issued an ALTER TABLE ... DISABLE KEYS)
then it will result in error: HA_ERR_WRONG_INDEX.
This patch addresses this issue by making the slave thread also
check whether the key is active or not before actually using it.
Invalid (old?) table or database name in logs
Problem was still not completely fixed, due to
qouting.
This is the server side only fix (in explain_filename),
the change from filename_to_tablename to use explain_filename
in the InnoDB code must be done before the bug is
fixed.
mysql-test/include/have_not_innodb_plugin.inc:
Bug#32430: 'show innodb status' causes errors
Invalid (old?) table or database name in logs
Added include file to allow test for only the
'old' built-in innodb engine
mysql-test/r/not_true.require:
Bug#32430: 'show innodb status' causes errors
Invalid (old?) table or database name in logs
Added require to match 'not' TRUE
mysql-test/r/partition_innodb_builtin.result:
Bug#32430: 'show innodb status' causes errors
Invalid (old?) table or database name in logs
New result file for partitioning specific to
the 'old' built-in innodb engine
mysql-test/r/partition_innodb_plugin.result:
Bug#32430: 'show innodb status' causes errors
Invalid (old?) table or database name in logs
New result file for partitioning specific to
the new plugin innodb engine
mysql-test/t/disabled.def:
Bug#32430: 'show innodb status' causes errors
Invalid (old?) table or database name in logs
Disabling the new test until the fix is
included in the InnoDB source too.
mysql-test/t/partition_innodb_builtin.test:
Bug#32430: 'show innodb status' causes errors
Invalid (old?) table or database name in logs
New test file for partitioning specific to
the 'old' built-in innodb engine
mysql-test/t/partition_innodb_plugin.test:
Bug#32430: 'show innodb status' causes errors
Invalid (old?) table or database name in logs
New test file for partitioning specific to
the new plugin innodb engine
sql/mysql_priv.h:
Bug#32430: 'show innodb status' causes errors
Invalid (old?) table or database name in logs
Added thd as a parameter to explain_filename
to be able to use the correct quote character
sql/sql_table.cc:
Bug#32430: 'show innodb status' causes errors
Invalid (old?) table or database name in logs
Changed explain_filename, so that it does qouting
correctly according to the sessions qoute char.
binlog-db-db / binlog-ignore-db
InnoDB will return an error if statement based replication is used
along with transaction isolation level READ-COMMITTED (or weaker),
even if the statement in question is filtered out according to the
binlog-do-db rules set. In this case, an error should not be printed.
This patch addresses this issue by extending the existing check in
external_lock to take into account the filter rules before deciding to
print an error. Furthermore, it also changes decide_logging_format to
take into consideration whether the statement is filtered out from
binlog before decision is made.
sql/sql_base.cc:
Changed the check on decide_logging_format to take into account
whether statement is filtered or not in SBR.
sql/sql_class.cc:
Added the thd_binlog_filter_ok to INNODB_COMPATIBILITY_HOOKS set.
storage/innobase/handler/ha_innodb.cc:
Extended check in external_lock to take into consideration the
filtering when deciding to throw an error.
storage/innobase/handler/ha_innodb.h:
Added declaration of new hook.
storage/innodb_plugin/handler/ha_innodb.cc:
Extended check in external_lock to take into consideration the
filtering when deciding to throw an error.
storage/innodb_plugin/handler/ha_innodb.h:
Added declaration of new hook.
when compiled with Sun Studio compiler).
The thing is that Sun Studio compiler calls destructor of stack
objects when pthread_exit() is called. That triggered an assertion
in DBUG_ENTER()/DBUG_RETURN() validation logic (if DBUG_ENTER() is
used in the beginning of function, all returns should be replaced
by DBUG_RETURN/DBUG_VOID_RETURN macros).
A fix is to explicitly use DBUG_LEAVE macro.
The "socket" variable is not available on Windows even though
the --socket option can be used to specify the pipe name for
local connections that use a named pipe.
The solution is to ensure that the variable is always defined.
mysql-test/r/windows.result:
Add test case result for Bug#45498
mysql-test/t/windows.test:
Add test case for Bug#45498
sql/set_var.cc:
socket variable must always be present.
the fix is reverted from 5.1, mysql-pe as
unnecessary(no valgrind warnings there).
sql/sql_select.cc:
the fix is reverted from 5.1, mysql-pe as
unnecessary(no valgrind warnings there).
checksum)"
The problem was that checksum of GEOMETRY type used memory addresses
in the computation, making it un-repeatable thus useless.
(This patch is a backport from 6.0 branch)
mysql-test/r/myisam.result:
test case for bug35570 that same tables give same checksums
mysql-test/t/myisam.test:
test case for bug35570 that same tables give same checksums
sql/sql_table.cc:
Type GEOMETRY is implemented on top of type BLOB, so, just like for BLOB,
its 'field' contains pointers which it does not make sense to include in
the checksum; it rather has to be converted to a string and then we can
compute the checksum.
Despite copying the value of the old table's row type
we don't always have to mark row type as being specified.
Innodb uses this to check if it can do fast ALTER TABLE
or not.
Fixed by correctly flagging the presence of row_type
only when it's actually changed.
Added a test case for 39200.
query
The fix for bug 46749 removed the check for OUTER_REF_TABLE_BIT
and substituted it for a check on the presence of
Item_ident::depended_from.
Removing it altogether was wrong : OUTER_REF_TABLE_BIT should
still be checked in addition to depended_from (because it's not
set in all cases and doesn't contradict to the check of depended_from).
Fixed by returning the old condition back as a compliment to the
new one.
But there is no Last_IO_Error reported.
On the master, if a binary log event is larger than max_allowed_packet,
ER_MASTER_FATAL_ERROR_READING_BINLOG and the specific reason of this error is
sent to a slave when it requests a dump from the master, thus leading
the I/O thread to stop.
On a slave, the I/O thread stops when receiving a packet larger than max_allowed_packet.
In both cases, however, there was no Last_IO_Error reported.
This patch adds code to report the Last_IO_Error and exact reason before stopping the
I/O thread and also reports the case the out memory pops up while
handling packets from the master.
sql/sql_repl.cc:
The master send the Specific reasons instead of "error reading log entry" to the slave which is requesting a dump.
if an fatal error is returned by read_log_event function.
"insert into.. select * from"
When inserting into a partitioned table using 'insert into
<target> select * from <src>', read_buffer_size bytes of memory
are allocated for each partition in the target table.
This resulted in large memory consumption when the number of
partitions are high.
This patch introduces a new method which tries to estimate the
buffer size required for each partition and limits the maximum
buffer size used to maximum of 10 * read_buffer_size,
11 * read_buffer_size in case of monotonic partition functions.
sql/ha_partition.cc:
Introduced a method ha_partition::estimate_read_buffer_size
to estimate buffer size required for each partition.
Method ha_partition::start_part_bulk_insert updated
to update the read_buffer_size before calling bulk upload
in storage engines.
Added thd in ha_partition::start_part_bulk_insert method signature.
sql/ha_partition.h:
Introduced a method ha_partition::estimate_read_buffer_size.
Added thd in ha_partition::start_part_bulk_insert method signature.
additional backport of of bug43138 fix
mysql-test/t/myisam-system.test:
additional backport of of bug43138 fix
sql/sql_db.cc:
additional backport of of bug43138 fix
When parsing the service installation parameter in
default_service_handling() make sure the value of the
optional parameter doesn't overwrite it's name.
Problem: LOGGER::general_log_write() relied on valid "thd" parameter passed
but had inconsistent "if (thd)" check.
Fix: as we always pass a valid "thd" parameter to the method,
redundant check removed.
sql/log.cc:
Fix for bug#47130: misplaced or redundant check for null pointer?
- code clean-up, as we rely on the "thd" parameter in the
LOGGER::general_log_write(), redundant "if (thd)" check removed,
added assert(thd) instead.
The problem is that argument buffer can be used as result buffer
and it leads to argument value change.
The fix is to use 'old buffer' as result buffer only
if first argument is not constant item.
mysql-test/r/func_str.result:
test result
mysql-test/t/func_str.test:
test case
sql/item_strfunc.cc:
The problem is that argument buffer can be used as result buffer
and it leads to argument value change.
The fix is to use 'old buffer' as result buffer only
if first argument is not constant item.
In RBR, There is an inconsistency between slaves and master.
When INSERT statement which includes an auto_increment field is executed,
Store engine of master will check the value of the auto_increment field.
It will generate a sequence number and then replace the value, if its value is NULL or empty.
if the field's value is 0, the store engine will do like encountering the NULL values
unless NO_AUTO_VALUE_ON_ZERO is set into SQL_MODE.
In contrast, if the field's value is 0, Store engine of slave always generates a new sequence number
whether or not NO_AUTO_VALUE_ON_ZERO is set into SQL_MODE.
SQL MODE of slave sql thread is always consistency with master's.
Another variable is related to this bug.
If generateing a sequence number is decided by the values of
table->auto_increment_field_not_null and SQL_MODE(if includes MODE_NO_AUTO_VALUE_ON_ZERO)
The table->auto_increment_is_not_null is FALSE, which causes this bug to appear. ..
partial backport of bug43138 fix
mysql-test/r/warnings.result:
test result
mysql-test/t/warnings.test:
test case
sql/sql_class.cc:
partial backport of bug43138 fix
sql/sql_class.h:
partial backport of bug43138 fix
sql/sql_table.cc:
partial backport of bug43138 fix
Create temporary InnoDB table fails on case insensitive
filesystems, when lower_case_table_names is 2 (e.g. OS X)
and temporary directory path contains upper case letters.
The problem was that tmpdir prefix was converted to lower
case when table was created, but was passed as is when
table was opened.
Fixed by leaving tmpdir prefix part intact.
mysql-test/r/lowercase_mixed_tmpdir_innodb.result:
A test case for BUG#45638.
mysql-test/t/lowercase_mixed_tmpdir_innodb-master.opt:
A test case for BUG#45638.
mysql-test/t/lowercase_mixed_tmpdir_innodb-master.sh:
A test case for BUG#45638.
mysql-test/t/lowercase_mixed_tmpdir_innodb.test:
A test case for BUG#45638.
sql/handler.cc:
Fixed get_canonical_filename() to not lowercase filesystem
path prefix for temporary tables.
can crash under load
Backport from 5.1.
Does also include key cache fixes from:
Bug 44068 (RESTORE can disable the MyISAM Key Cache)
Bug 40944 (Backup: crash after myisampack)
include/keycache.h:
Bug#17332 - changing key_buffer_size on a running server
can crash under load
Added KEY_CACHE components in_resize and waiting_for_resize_cnt.
myisam/mi_preload.c:
Bug#17332 - changing key_buffer_size on a running server
can crash under load
Added code to allow LOAD INDEX to load indexes of different block size.
mysys/mf_keycache.c:
Bug#17332 - changing key_buffer_size on a running server
can crash under load
.
Changed resize_key_cache() to not disable the key cache
after the flush phase. Changed queue handling to use
standard functions. Wake all threads waiting on resize_queue.
We can now have read/write threads waiting there (see below).
.
Combined add_to_queue() and the wait loops that were always
following it to the new function wait_on_queue().
Combined release_queue() and the condition that was always
preceding it to the new function release_whole_queue().
.
Added code to flag and respect the exceptional situation
BLOCK_IN_EVICTION.
.
Rewrote the resize branch of find_key_block().
.
Added code to the eviction handling in find_key_block()
to catch more exceptional cases.
.
Changed key_cache_read(), key_cache_insert() and key_cache_write()
so that they lock keycache->cache_lock whenever the key cache is
initialized. Checking for a disabled cache and incrementing and
decrementing the "resize counter" is always done within the lock.
Locking and unlocking as well as counting the "resize counter" is
now done once outside the loop. All three functions can now handle
a NULL return from find_key_block. This happens in the flush phase
of a resize and demands direct file I/O. Care is taken for
secondary requests (PAGE_WAIT_TO_BE_READ) to wait in any case.
Moved block status changes behind the copying of buffer data.
key_cache_insert() does now read the block if the caller did
supply less data than a full cache block.
key_cache_write() does now take care of parallel running flushes
(BLOCK_FOR_UPDATE, BLOCK_IN_FLUSHWRITE).
.
Changed free_block() to un-initialize block variables in the
correct order and respect an exceptional BLOCK_IN_EVICTION state.
.
Changed flushing to take care for parallel running writes.
Changed flushing to avoid freeing blocks in eviction.
Changed flushing to consider that parallel writes can move blocks
from the file_blocks hash to the changed_blocks hash.
Changed flushing to take care for other parallel flushes.
Changed flushing to assure that it ends with everything flushed.
Optimized normal flush at end of statement (FLUSH_KEEP),
but let other flush types be stringent.
.
Added some comments and debugging statements.
mysys/my_static.c:
Bug#17332 - changing key_buffer_size on a running server
can crash under load
Removed an unused global variable.
sql/ha_myisam.cc:
Bug#17332 - changing key_buffer_size on a running server
can crash under load
Moved an automatic (stack) variable to the scope where it is used.
sql/sql_table.cc:
Bug#17332 - changing key_buffer_size on a running server
can crash under load
Changed TL_READ to TL_READ_NO_INSERT in mysql_preload_keys.
The parser rule for expressions in a udf parameter list contains
two hacks:
First, the parser input stream is read verbatim, bypassing
the lexer.
Second, the Item::name field is overwritten. If the argument to a
udf was a field, the field's name as seen by name resolution was
overwritten this way.
If the field name was quoted or escaped, it would appear as e.g. "`field`".
Fixed by not overwriting field names.
mysql-test/r/udf.result:
Bug#46259: Test result.
mysql-test/t/udf.test:
Bug#46259: Test case.
sql/sql_yacc.yy:
Bug#46259: Fix.
The external 'for' loop in remove_dup_with_compare() handled
HA_ERR_RECORD_DELETED by just starting over without advancing
to the next record which caused an infinite loop.
This condition could be triggered on certain data by a SELECT
query containing DISTINCT, GROUP BY and HAVING clauses.
Fixed remove_dup_with_compare() so that we always advance to
the next record when receiving HA_ERR_RECORD_DELETED from
rnd_next().
mysql-test/r/distinct.result:
Added a test case for bug #46159.
mysql-test/t/distinct.test:
Added a test case for bug #46159.
sql/sql_select.cc:
Fixed remove_dup_with_compare() so that we always advance to
the next record when receiving HA_ERR_RECORD_DELETED from
rnd_next().
(Backport)
Problem is that when insert (ha_start_bulk_insert) in i partitioned table,
it will call ha_start_bulk_insert for every partition, used or not.
Solution is to delay the call to the partitions ha_start_bulk_insert until
the first row is to be inserted into that partition
sql/ha_partition.cc:
Bug#35845: unneccesary call to ha_start_bulk_insert for not used partitions
Using a bitmap for keeping record of which partitions for which
ha_start_bulk_insert has been called, and check against that if one
should call it before continue with the insert/update, or if it has already
been called.
This way it will only call ha_start_bulk_insert for the used partitions.
There is also a little prediction on how many rows that will be inserted into
the current partition, it will guess on equal distribution of the records
across all partitions, accept for the first used partition, which will guess
at 50% of the given estimate, if it is a monotonic partitioning function.
sql/ha_partition.h:
Bug#35845: unneccesary call to ha_start_bulk_insert for not used partitions
Added help variables and function for delaying ha_bulk_insert until it has
to be called.
Fixed a comment.
Incremental patch part 2
Removing dead code and changing a note level message to a warning.
sql/sql_plugin.cc:
* Remove free_slots. The only purpose for this variable was to trigger
a redundant warning message and it failed.
* Change the note level message about shutting down plugins which
didn't end nicely to a warning level message. (If this shutdown
fails and there still are reference counts in the plugin an
additional error level message is emitted)
on subquery inside a SP
Problem: repeated call of a SP containing an incorrect query with a
subselect may lead to failed ASSERT().
Fix: set proper sublelect's state in case of error occured during
subquery transformation.
mysql-test/r/sp.result:
Fix for bug#46629: Item_in_subselect::val_int(): Assertion `0'
on subquery inside a SP
- test result.
mysql-test/t/sp.test:
Fix for bug#46629: Item_in_subselect::val_int(): Assertion `0'
on subquery inside a SP
- test case.
sql/item_subselect.cc:
Fix for bug#46629: Item_in_subselect::val_int(): Assertion `0'
on subquery inside a SP
- don't set Item_subselect::changed in the Item_subselect::fix_fields()
if an error occured during subquery transformation.
That prevents us of further processing incorrect subqueries after
Item_in_subselect::select_in_like_transformer().
Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.
mysql-test/r/explain.result:
test result
mysql-test/t/explain.test:
test case
sql/sql_select.cc:
Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.
name as existing view
When trying to create a table with the same name as existing view with
join, mysql server crashes.
The problem is when create table is issued with the same name as view, while
verifying with the existing tables, we assume that base table object is
created always.
In this case, since it is a view over multiple tables, we don't have the
mysql derived table object.
Fixed the logic which checks if there is an existing table to not to assume
that table object is created when the base table is view over multiple
tables.
mysql-test/r/create.result:
BUG#46384 - mysqld segfault when trying to create table with same
name as existing view
Testcase for the bug
mysql-test/t/create.test:
BUG#46384 - mysqld segfault when trying to create table with same
name as existing view
Testcase for the bug
sql/sql_insert.cc:
BUG#46384 - mysqld segfault when trying to create table with same
name as existing view
Fixed create_table_from_items() method to properly check, if the base table
is a view over multiple tables.
Inserting a negative value in the autoincrement column of a
partitioned innodb table was causing the value of the auto
increment counter to wrap around into a very large positive
value. The consequences are the same as if a very large positive
value was inserted into a column, e.g. reduced autoincrement
range, failure to read autoincrement counter.
The current patch ensures that before calculating the next
auto increment value, the current value is within the positive
maximum allowed limit.
mysql-test/suite/parts/inc/partition_auto_increment.inc:
Bug#45823 Assertion failure in file row/row0mysql.c line 1386
Adds tests for performing insert,update and delete on a partition
table with negative auto_increment values.
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
Bug#45823 Assertion failure in file row/row0mysql.c line 1386
Result file for the innodb engine.
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
Bug#45823 Assertion failure in file row/row0mysql.c line 1386
Result file for the memory engine.
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
Bug#45823 Assertion failure in file row/row0mysql.c line 1386
Result file for the myisam engine.
mysql-test/suite/parts/r/partition_auto_increment_ndb.result:
Bug#45823 Assertion failure in file row/row0mysql.c line 1386
Result file for the ndb engine.
mysql-test/suite/parts/t/partition_auto_increment_archive.test:
Bug#45823 Assertion failure in file row/row0mysql.c line 1386
Adds a variable that allows the Archive engine to skip tests
that involve insertion of negative auto increment values.
mysql-test/suite/parts/t/partition_auto_increment_blackhole.test:
Bug#45823 Assertion failure in file row/row0mysql.c line 1386
Adds a variable that allows the Blackhole engine to skip tests
that involve insertion of negative auto increment values.
sql/ha_partition.cc:
Bug#45823 Assertion failure in file row/row0mysql.c line 1386
Ensures that the current value is lesser than the upper limit
for the type of the field before setting the next auto increment
value to be calculated.
sql/ha_partition.h:
Bug#45823 Assertion failure in file row/row0mysql.c line 1386
Modifies the set_auto_increment_if_higher function, to take
into account negative auto increment values when doing a
comparison.
function,file sql_base.cc
When uncacheable queries are written to a temp table the optimizer must
preserve the original JOIN structure, because it is re-using the JOIN
structure to read from the resulting temporary table.
This was done only for uncacheable sub-queries.
But top level queries can also benefit from this mechanism, specially if
they're using index access and need a reset.
Fixed by not limiting the saving of JOIN structure to subqueries
exclusively.
Added a new test file to extend the existing (large) subquery.test.
CREATE TABLE...LIKE...
The mysql server option 'sync_frm' is ignored when table is created with
syntax CREATE TABLE .. LIKE..
Fixed by adding the MY_SYNC flag and calling my_sync() from my_copy() when
the flag is set.
In mysql_create_table(), when the 'sync_frm' is set, MY_SYNC flag is passed
to my_copy().
Note: TestCase is not attached and can be tested manually using debugger.
client/Makefile.am:
BUG#46591 - .frm file isn't sync'd with sync_frm enabled for
CREATE TABLE...LIKE...
add my_sync to sources as it is used in my_copy() method
include/my_sys.h:
BUG#46591 - .frm file isn't sync'd with sync_frm enabled for
CREATE TABLE...LIKE...
MY_SYNC flag is added to call my_sync() method
mysys/my_copy.c:
BUG#46591 - .frm file isn't sync'd with sync_frm enabled for
CREATE TABLE...LIKE...
my_sync() is method is called when MY_SYNC is set in my_copy()
sql/sql_table.cc:
BUG#46591 - .frm file isn't sync'd with sync_frm enabled for
CREATE TABLE...LIKE...
Fixed mysql_create_like_table() to call my_sync() when opt_sync_frm variable
is set
During start up some plugins are disabled by default. This caused an additional
warning level message to be emitted as a result of a previous bug patch. Since
there is risk of unnecessary confusion regarding the operation level of the server
the redundant information is removed.
extraneous file
Online/fast ALTER TABLE of a partitioned table may leave
temporary file in database directory.
Fixed by removing unnecessary call to
handler::ha_create_handler_files(), which was creating
partitioning definition file.
mysql-test/r/partition_innodb.result:
A test case for BUG#46483.
mysql-test/t/partition_innodb.test:
A test case for BUG#46483.
sql/unireg.cc:
Do not call ha_create_handler_files() when we were requested
to create only dot-frm file.
results in server crash
check_group_min_max_predicates() assumed the input condition
item to be one of COND_ITEM, SUBSELECT_ITEM, or FUNC_ITEM.
Since a condition of the form "field" is also a valid condition
equivalent to "field <> 0", using such a condition in a query
where the loose index scan was chosen resulted in a debug
assertion failure.
Fixed by handling conditions of the FIELD_ITEM type in
check_group_min_max_predicates().
mysql-test/r/group_min_max.result:
Added a test case for bug #46607.
mysql-test/t/group_min_max.test:
Added a test case for bug #46607.
sql/opt_range.cc:
Handle conditions of the FUNC_ITEM type in
check_group_mix_max_predicates().
If an EVENT is created without the DEFINER clause set explicitly or with it set
to CURRENT_USER, the master and slaves become inconsistent. This issue stems from
the fact that in both cases, the DEFINER is set to the CURRENT_USER of the current
thread. On the master, the CURRENT_USER is the mysqld's user, while on the slave,
the CURRENT_USER is empty for the SQL Thread which is responsible for executing
the statement.
To fix the problem, we do what follows. If the definer is not set explicitly,
a DEFINER clause is added when writing the query into binlog; if 'CURRENT_USER' is
used as the DEFINER, it is replaced with the value of the current user before
writing to binlog.
mysql-test/suite/rpl/r/rpl_create_if_not_exists.result:
Updated the result file after fixing bug#44331
mysql-test/suite/rpl/r/rpl_drop_if_exists.result:
Updated the result file after fixing bug#44331
mysql-test/suite/rpl/r/rpl_events.result:
Test result of Bug#44331
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
Updated the result file after fixing bug#44331
mysql-test/suite/rpl/t/rpl_events.test:
Added test to verify if the definer is consistent between master and slave
when the event is created without the DEFINER clause set explicitly or the
DEFINER is set to CURRENT_USER
sql/events.cc:
The "create_query_string" function is added to create a new query string
for removing executable comments.
sql/sql_yacc.yy:
The remember_name token was added for recording the offset of EVENT_SYM.
with gcc 4.3.2
This patch fixes a number of GCC warnings about variables used
before initialized. A new macro UNINIT_VAR() is introduced for
use in the variable declaration, and LINT_INIT() usage will be
gradually deprecated. (A workaround is used for g++, pending a
patch for a g++ bug.)
GCC warnings for unused results (attribute warn_unused_result)
for a number of system calls (present at least in later
Ubuntus, where the usual void cast trick doesn't work) are
also fixed.
client/mysqlmanager-pwgen.c:
A fix for warn_unused_result, adding fallback to use of
srand()/rand() if /dev/random cannot be used. Also actually
adds calls to rand() in the second branch so that it actually
creates a random password.
client/mysql.cc:
Remove leading whitespace.
Remove extra text after #else directive.
client/mysqldump.c:
Function does not take a parameter.
mysys/array.c:
buffer is a uchar pointer.
sql/item.cc:
Assert if it should not happen.
storage/myisam/mi_check.c:
Cast to expected type. This is probably a bug, but it is
casted in a similar way in another part of the code.
storage/ndb/include/mgmapi/ndb_logevent.h:
Apply fix from cluster team.
tests/mysql_client_test.c:
Remove extraneous slash.
sql/opt_range.cc:
Removed duplicate code (if statement must have been duplicated during earlier merge).
sql/sql_partition.cc:
After mergeing bug#46362 and bug#20577, the NULL partition was also searched
when col = const, fixed by checking if = or range.
When a connection is dropped any remaining temporary table is also automatically
dropped and the SQL statement of this operation is written to the binary log in
order to drop such tables on the slave and keep the slave in sync. Specifically,
the current code base creates the following type of statement:
DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `db`.`table`;
Unfortunately, appending the database to the table name in this manner circumvents
the replicate-rewrite-db option (and any options that check the current database).
To solve the issue, we started writing the statement to the binary as follows:
use `db`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `table`;
Slave does not correctly handle "expected errors" leading to inconsistencies
between the mater and slave. Specifically, when a statement changes both
transactional and non-transactional tables, the transactional changes are
automatically rolled back on the master but the slave ignores the error and
does not roll them back thus leading to inconsistencies.
To fix the problem, we automatically roll back a statement that fails on
the slave but note that the transaction is not rolled back unless a "rollback"
command is in the relay log file.
mysql-test/extra/rpl_tests/rpl_mixing_engines.test:
Enabled item 13.e which was disabled because of the bug fixed by the
current and removed item 14 which was introduced by mistake.
field references
This error requires a combination of factors :
1. An "impossible where" in the outermost SELECT
2. An aggregate in the outermost SELECT
3. A correlated subquery with a WHERE clause that includes an outer
field reference as a top level WHERE sargable predicate
When JOIN::optimize detects an "impossible WHERE" it will bail out
without doing the rest of the work and initializations. It will not
call make_join_statistics() as well. And make_join_statistics fills
in various structures for each table referenced.
When processing the result of the "impossible WHERE" the query must
send a single row of data if there are aggregate functions in it.
In this case the server marks all the aggregates as having received
no rows and calls the relevant Item::val_xxx() method on the SELECT
list. However if this SELECT list happens to contain a correlated
subquery this subquery is evaluated in a normal evaluation mode.
And if this correlated subquery has a reference to a field from the
outermost "impossible where" SELECT the add_key_fields will mistakenly
consider the outer field reference as a "local" field reference when
looking for sargable predicates.
But since the SELECT where the outer field reference refers to is not
completely initialized due to the "impossible WHERE" in this level
we'll get a NULL pointer reference.
Fixed by making a better condition for discovering if a field is "local"
to the SELECT level being processed.
It's not enough to look for OUTER_REF_TABLE_BIT in this case since
for outer references to constant tables the Item_field::used_tables()
will return 0 regardless of whether the field reference is from the
local SELECT or not.
The crash happens because select_union object is used as result set
for queries which have derived tables.
select_union use temporary table as data storage and if
fields count exceeds 10(count of values for procedure ANALYSE())
then we get a crash on fill_record() function.
mysql-test/r/analyse.result:
test result
mysql-test/r/subselect.result:
result fix
mysql-test/t/analyse.test:
test case
mysql-test/t/subselect.test:
test fix
sql/sql_yacc.yy:
The crash happens because select_union object is used as result set
for queries which have derived tables.
select_union use temporary table as data storage and if
fields count exceeds 10(count of values for procedure ANALYSE())
then we get a crash on fill_record() function.
binlog
Mixing transactional (T) and non-transactional (N) tables on behalf of a
transaction may lead to inconsistencies among masters and slaves in STATEMENT
mode. The problem stems from the fact that although modifications done to
non-transactional tables on behalf of a transaction become immediately visible
to other connections they do not immediately get to the binary log and therefore
consistency is broken. Although there may be issues in mixing T and M tables in
STATEMENT mode, there are safe combinations that clients find useful.
In this bug, we fix the following issue. Mixing N and T tables in multi-level
(e.g. a statement that fires a trigger) or multi-table table statements (e.g.
update t1, t2...) were not handled correctly. In such cases, it was not possible
to distinguish when a T table was updated if the sequence of changes was N and T.
In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect
that both a N and T tables were changed. To circumvent this issue, we check if an
engine is registered in the handler's list and changed something which means that
a T table was modified.
Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or
ROW modes completely safe.
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
Truncate statement is wrapped in BEGIN/COMMIT.
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
Truncate statement is wrapped in BEGIN/COMMIT.
Problem was that the partition containing NULL values
was pruned away, since '2001-01-01' < '2001-02-00' but
TO_DAYS('2001-02-00') is NULL.
Added the NULL partition for RANGE/LIST partitioning on TO_DAYS()
function to be scanned too.
Also fixed a bug that added ALLOW_INVALID_DATES to sql_mode
(SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
partitioned table would add it).
mysql-test/include/partition_date_range.inc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added include file to decrease test code duplication
mysql-test/r/partition_pruning.result:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added test results
mysql-test/r/partition_range.result:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Updated test result.
This fix adds the partition containing NULL values to
the list of partitions to be scanned.
mysql-test/t/partition_pruning.test:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added test case
sql/item.h:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added MONOTONIC_*INCREASE_NOT_NULL values to be used by TO_DAYS.
sql/item_timefunc.cc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Calculate the number of days as return value even for invalid dates.
This is so that pruning can be used even for invalid dates.
sql/opt_range.cc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Fixed a bug that added ALLOW_INVALID_DATES to sql_mode
(SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
partitioned table would add it).
sql/partition_info.h:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Resetting ret_null_part when a single partition is to be used, this
to avoid adding the NULL partition.
sql/sql_partition.cc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Always include the NULL partition if RANGE or LIST.
Use the returned value for the function for pruning, even if
it is marked as NULL, so that even '2000-00-00' can be
used for pruning, even if TO_DAYS('2000-00-00') is NULL.
Changed == to >= in get_next_partition_id_list to avoid
crash if part_iter->part_nums is not correctly setup.
There were a problem since pruning uses the field
for comparison (while evaluate_join_record uses longlong),
resulting in pruning failures when comparing DATE to DATETIME.
Fix was to always comparing DATE vs DATETIME as DATETIME,
by adding ' 00:00:00' to the DATE string.
And adding optimization for comparing with 23:59:59, so that
DATETIME_col > '2001-02-03 23:59:59' ->
TO_DAYS(DATETIME_col) > TO_DAYS('2001-02-03 23:59:59') instead
of '>='.
mysql-test/r/partition_pruning.result:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Updated result-file
mysql-test/t/partition_pruning.test:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Added testcases.
sql-common/my_time.c:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
removed duplicate assignment.
sql/item.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Changed field_is_equal_to_item into field_cmp_to_item, to
better handling DATE vs DATETIME comparision.
sql/item.h:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Updated comment
sql/item_timefunc.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Added optimization (pruning) of DATETIME where time-part is
23:59:59
sql/opt_range.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Using the new stored_field_cmp_to_item for better pruning.
The problem was that creating a DECIMAL column from a decimal
value could lead to a failed assertion as decimal values can
have a higher precision than those attached to a table. The
assert could be triggered by creating a table from a decimal
with a large (> 30) scale. Also, there was a problem in
calculating the number of digits in the integral and fractional
parts if both exceeded the maximum number of digits permitted
by the new decimal type.
The solution is to ensure that truncation procedure is executed
when deducing a DECIMAL column from a decimal value of higher
precision. If the integer part is equal to or bigger than the
maximum precision for the DECIMAL type (65), the integer part
is truncated to fit and the fractional becomes zero. Otherwise,
the fractional part is truncated to fit into the space left
after the integer part is copied.
This patch borrows code and ideas from Martin Hansson's patch.
mysql-test/r/type_newdecimal.result:
Add test case result for Bug#45261. Also, update test case to
reflect that an additive operation increases the precision of
the resulting type by 1.
mysql-test/t/type_newdecimal.test:
Add test case for Bug#45261
sql/field.cc:
Added DBUG_ASSERT to ensure object's invariant is maintained.
Implement method to create a field to hold a decimal value
from an item.
sql/field.h:
Explain member variable. Add method to create a new decimal field.
sql/item.cc:
The precision should only be capped when storing the value
on a table. Also, this makes it impossible to calculate the
integer part if Item::decimals (the scale) is larger than the
precision.
sql/item.h:
Simplify calculation of integer part.
sql/item_cmpfunc.cc:
Do not limit the precision. It will be capped later.
sql/item_func.cc:
Use new method for allocating a new decimal field.
Add a specialized method for retrieving the precision
of a user variable item.
sql/item_func.h:
Add method to return the precision of a user variable.
sql/item_sum.cc:
Use new method for allocating a new decimal field.
sql/my_decimal.h:
The integer part could be improperly calculated for a decimal
with 31 digits in the fractional part.
sql/sql_select.cc:
Use new method which truncates the integer or decimal parts
as needed.
The code was using a special global buffer for the value of IS NULL ranges.
This was not always long enough to be copied by a regular memcpy. As a
result read buffer overflows may occur.
Fixed by setting the null byte to 1 and setting the rest of the field disk image
to NULL with a bzero (instead of relying on the buffer and memcpy()).
