in stored procedure.
The problem was that MySQL used unnecessarily large amounts of
memory if user variables were used as an argument to CONCAT or
CONCAT_WS -- 16M per each user variable used.
Technically, it happened because MySQL used the following
allocation strategy for string functions to avoid multiple
realloc() calls: in the virtual operation fix_length_and_dec()
the attribute max_length was calculated as a sum of max_length
values for each argument.
Although this approach worked well for small (or fixed) data types,
there could be a problem if there as a user variable among
the arguments of a string function -- max_length of the function
would be 16M (as the max_length of a user variable is 16M).
Both CONCAT() and CONCAT_WS() functions suffer from this problem.
The fix is to do not use meta-data for allocating memory.
The following strategy is proposed instead: allocate the exact
length of the result string at the first record, double the amount
of memory allocated when it is required.
No test case for this bug because there is no way to test memory
consumption in a robust way with our test suite.
After adding an index the <VARBINARY> IN (SELECT <BINARY> ...)
clause returned a wrong result: the VARBINARY value was illegally padded
with zero bytes to the length of the BINARY column for the index search.
(<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.
UNIQUE (eq-ref) lookups result in table being considered as a "constant" table.
Queries that consist of only constant tables are processed in do_select() in a
special way that doesn't invoke evaluate_join_record(), and therefore doesn't
increase the counters join->examined_rows and join->thd->row_count.
The patch increases these counters in this special case.
NOTICE:
This behavior seems to contradict what the documentation says in Sect. 5.11.4:
"Queries handled by the query cache are not added to the slow query log, nor
are queries that would not benefit from the presence of an index because the
table has zero rows or one row."
No test case in 5.0 as issue shows only in slow query log, and other counters
can give subtly different values (with regard to counting in create_sort_index(),
synthetic rows in ROLLUP, etc.).
in mysql_creata_like_table() we 'downcase' the complete path to the
.frm file. It works fine in standalone case as there usually
we only have './' as a path to the datahome, but doesn't work in
the embedded server where we add the real path there, so if a
directory has uppercase letters in it's name, it won't be found.
Fixed by 'downcasing' only database/table pair.
BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME
in comparisons than greater-than and less-than were. ChangeSet makes < >
comparisons similarly robust with regard to trailing garbage (" GMT-1")
and "missing" leading zeros. Now all three comparators behave similarly
in that they throw a warning for "junk" at the end of the data, but then
proceed anyway if possible. Before < > fell back on a string- (rather than
date-) comparison when a warning-condition was raised in the string-to-date
conversion. Now the fallback only happens on actual errors, while warning-
conditions still result in a warning being to delivered to the client.
Problem: there was no standard syntax error when
creating partitions with syntax error in
the partitioning clause.
Solution: added "Syntax error: " to the error message
Problem: the table's INDEX and DATA DIR was taken
directly from the table's first partition.
This allowed rename attack similar to
bug#32111 when ALTER TABLE REMOVE PARTITIONING
Solution: Silently ignore the INDEX/DATA DIR
for the table. (Like some other storage engines
do).
Partitioned tables do not support DATA/INDEX
DIR on the table level, only on its partitions.
Between 5.0 and 5.1, the step of incrementing the global query id
changed, which broke how the profiler noticed when a new query had
started. That reset the state list and caused all but the last
five (or so) states to be thrown away.
Now, don't watch for query_id changes in the lower level.
Add a bogus state change at the end of profiling so that the last
real state change is timed.
Emit source reference for the start of the span of time instead of
the end of it.
The bug is a regression introduced by the fix for bug30596. The problem
was that in cases when groups in GROUP BY correspond to only one row,
and there is ORDER BY, the GROUP BY was removed and the ORDER BY
rewritten to ORDER BY <group_by_columns> without checking if the
columns in GROUP BY and ORDER BY are compatible. This led to
incorrect ordering of the result set as it was sorted using the
GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers
from ORDER BY even if its columns were compatible with the GROUP BY
ones.
This patch fixes the regression by checking if ORDER BY columns form a
prefix of the GROUP BY ones, and rewriting ORDER BY only in that case,
preserving the ASC/DESC modifiers. That check is sufficient, since the
GROUP BY columns contain a unique index.
When running mysqlbinlog on a 64-bit machine with a corrupt relay log,
it causes mysqlbinlog to crash. In this case, the crash is caused
because a request for 18446744073709534806U bytes is issued, which
apparantly can be served on a 64-bit machine (speculatively, I assume)
but this causes the memcpy() issued later to copy the data to segfault.
The request for the number of bytes is caused by a computation
of data_len - server_vars_len where server_vars_len is corrupt in such
a sense that it is > data_len. This causes a wrap-around, with the
the data_len given above.
This patch adds a check that if server_vars_len is greater than
data_len before the substraction, and aborts reading the event in
that case marking the event as invalid. It also adds checks to see
that reading the server variables does not go outside the bounds
of the available space, giving a limited amount of integrity check.
The "mysql client in mysqld"(which is used by
replication and federated) should use alarms instead of setting
socket timeout value if the rest of the server uses alarm. By
always calling 'my_net_set_write_timeout'
or 'net_set_read_timeout' when changing the timeout value(s), the
selection whether to use alarms or timeouts will be handled by
ifdef's in those two functions.
This is minimal backport of patch for BUG#26664, which was pushed
to 5.0 and up.
Affects 4.1 only.
causes out of memory errors
The code in mysql_create_function() and mysql_drop_function() assumed
that the only reason for UDFs being uninitialized at that point is an
out-of-memory error during initialization. However, another possible
reason for that is the --skip-grant-tables option in which case UDF
initialization is skipped and UDFs are unavailable.
The solution is to check whether mysqld is running with
--skip-grant-tables and issue a proper error in such a case.
