and value-list
The server returns unexpected results if a right side of the
NOT IN clause consists of NULL value and some constants of
the same type, for example:
SELECT * FROM t WHERE NOT t.id IN (NULL, 1, 2)
may return 3, 4, 5 etc if a table contains these values.
The Item_func_in::val_int method has been modified:
unnecessary resets of an Item_func_case::has_null field
value has been moved outside of an argument comparison
loop. (Also unnecessary re-initialization of the null_value
field has been moved).
Problem was that ha_partition had HA_FILE_BASED flag set
(since it uses a .par file), but after open it uses the first partitions
flags, which results in different case handling for create and for
open.
Solution was to change the underlying partition name so it was consistent.
(Only happens when lower_case_table_names = 2, i.e. Mac OS X and storage
engines without HA_FILE_BASED, like InnoDB and Memory.)
(Recommit after adding rename of check_lowercase_names to
get_canonical_filename, and moved it from handler.h to mysql_priv.h)
NOTE: if a mixed case name for a partitioned table was created when
lower_case_table_name = 2 it should be renamed or dropped before using
the updated version (See bug#37402 for more info)
offset for time part in UUIDs was 1/1000 of what it
should be. In other words, offset was off.
Also handle the case where we count into the future
when several UUIDs are generated in one "tick", and
then the next call is late enough for us to unwind
some but not all of those borrowed ticks.
Lastly, handle the case where we keep borrowing and
borrowing until the tick-counter overflows by also
changing into a new "numberspace" by creating a new
random suffix.
offset for time part in UUIDs was 1/1000 of what it
should be. In other words, offset was off.
Also handle the case where we count into the future
when several UUIDs are generated in one "tick", and
then the next call is late enough for us to unwind
some but not all of those borrowed ticks.
Lastly, handle the case where we keep borrowing and
borrowing until the tick-counter overflows by also
changing into a new "numberspace" by creating a new
random suffix.
Problem: reading/writing data from/to an address without proper
alignment leads to SIGBUS on some platforms.
Fix: use the correct data type when dereferencing variable values.
problem was that ha_partition::records was not implemented, thus
using the default handler::records, which is not correct if the engine
does not support HA_STATS_RECORDS_IS_EXACT.
Solution was to implement ha_partition::records as a wrapper around
the underlying partitions records.
The rows column in explain partitions will now include the total
number of records in the partitioned table.
(recommit after removing out-commented code)
enabled)
Before this fix, the lexer and parser would treat the ';' character as a
different token (either ';' or END_OF_INPUT), based on convoluted logic,
which failed in simple cases where a stored procedure is implemented as a
single statement, and used in a multi query.
With this fix:
- the character ';' is always parsed as a ';' token in the lexer,
- parsing multi queries is implemented in the parser, in the 'query:' rules,
- the value of thd->client_capabilities, which is the capabilities
negotiated between the client and the server during bootstrap,
is immutable and not arbitrarily modified during parsing (which was the
root cause of the bug)
Problem was that auto_repair, is_crashed and check_and_repair was not
implemented in ha_partition.
Solution, implemented them as loop over all partitions for is_crashed and
check_and_repair, and using the first partition for auto_repair.
(Recommit after fixing review comments)
On certain kinds of errors (e.g., out of stack), a call to Item_func_
set_user_var::fix_fields() might fail. Since the return value of this
call was not checked inside User_var_log_event::exec_event(), continuing
execution after this will cause a crash inside Item_func_set_user_var::
update_hash().
The bug is fixed by aborting execution of the event with an error if
fix_fields() fails, since it is not possible to continue execution anyway.
When there is an error executing EXISTS predicates they return NULL as their string
or decimal value but don't set the NULL value flag.
Fixed by returning 0 (as a decimal or a string) on error exectuting the subquery.
Note that we can't return NULL as EXISTS is not supposed to return NULL.
Bug#12093 "SP not found on second PS execution if another thread
drops other SP in between" and
Bug#21294 "executing a prepared statement that executes a stored
function which was recreat"
Stored functions are resolved at prepared statement prepare only.
If someone flushes the stored functions cache between prepare and
execute, execution fails.
The fix is to detect the situation of the cache flush and automatically
reprepare the prepared statement after it.
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.
Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).
Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
InnoDB table, where all selected columns
belong to the same unique index key, returns
incorrect results
Server executes some queries via QUICK_GROUP_MIN_MAX_SELECT
(MIN/MAX optimization for queries with GROUP BY or DISTINCT
clause) and that optimization implies loose index scan, so all
grouping is done by the QUICK_GROUP_MIN_MAX_SELECT::get_next
method.
The server does not set the precomputed_group_by flag for some
QUICK_GROUP_MIN_MAX_SELECT queries and duplicates grouping by
call to the end_send_group function.
Fix: when the test_if_skip_sort_order function selects loose
index scan as a best way to satisfy an ORDER BY/GROUP BY type
of query, the precomputed_group_by flag has been set to use
end_send/end_write functions instead of end_send_group/
end_write_group functions.
Bug#35658 (An empty binary value leads to mysqld crash)
Before this fix, the following token
b''
caused the parser to crash when reading the binary value from the empty string.
The crash was caused by:
ptr+= max_length - 1;
because max_length is unsigned and was 0, causing an overflow.
With this fix, an empty binary literal b'' is parsed as a binary value 0,
in Item_bin_string.
Bug#35658 (An empty binary value leads to mysqld crash)
Before this fix, the following token
b''
caused the parser to crash when reading the binary value from the empty string.
The crash was caused by:
ptr+= max_length - 1;
because max_length is unsigned and was 0, causing an overflow.
With this fix, an empty binary literal b'' is parsed as a binary value 0,
in Item_bin_string.
Bug#35658 (An empty binary value leads to mysqld crash)
Before this fix, the following token
b''
caused the parser to crash when reading the binary value from the empty string.
The crash was caused by:
ptr+= max_length - 1;
because max_length is unsigned and was 0, causing an overflow.
With this fix, an empty binary literal b'' is parsed as a binary value 0,
in Item_bin_string.
The crash appeared to be a result of allocating an instance of Discrete_interval
automatically that that was referred in out-of-declaration scope.
Fixed with correcting backing up and restoring scheme of
auto_inc_intervals_forced, introduced by bug#33029, by means of shallow copying;
added simulation code that forces executing those fixes of the former bug that
targeted at master-and-slave having incompatible bug#33029-prone versions.
Another problem is that the backtrace facility wasn't being
enabled for non-Linux targets even if the target OS has the
backtrace functions. Also, the stacktrace functions inside
mysqltest were being used without proper checks for their
presence in the build.
If during a FLUSH PRIVILEGES the server fails to load the new privilege
tables, the error message is lost. This patch is a back port from 5.1 which
adresses this issue by setting the server in an error state if a failure
occurrs.
This patch also corrects an incorrect variable assignment which might
cause an error state to be reverted by coincidence.
The problem was that when a embedded linked version of mysqltest
crashed there was no way to obtain a stack trace if no core file
is available. Another problem is that the embedded version of
libmysql was not behaving (crash) the same as the non-embedded with
respect to sending commands to a explicitly closed connection.
The solution is to generate a mysqltest's stack trace on crash
and to enable "reconnect" if the connection handle was explicitly
closed so the behavior matches the non-embedded one.
The problem was that when comparing tables for a possible
fast alter table, the comparison was being performed using
the parsed information and not the final definition.
The solution is to use the possible final table layout to
compare if a fast alter is possible or not.
added a rule that use gcc to generate preprocessor output (gcc -E)
that can be then compared to a already generated output using
the diff utility.
Ran make test on the repository to verify changes.
