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.
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.
returns erroneous results
Used the wrong function when fixing 30480 which lead to
no stop on end_key resulting in duplicate results from index scan
Includes test cases for the duplicates 37327 and 37329,
Duplicate rows and bad performance/High Handler_read_next values
Recommit after merge issues
if cached query uses many tables
The problem was that query cache would not properly cache
queries which used 256 or more tables but yet would leave
behind query cache blocks pointing to freed (destroyed)
data. Later when invalidating (due to a truncate) query cache
would attempt to grab a lock which resided in the freed data,
leading to hangs or undefined behavior.
This was happening due to a improper return value from the
function responsible for registering the tables used in the
query (so the cache can be invalidated later if one of the
tables is modified). The function expected a return value of
type boolean (char, 8 bits) indicating success (1) or failure
(0) but the number of tables registered (unsigned int, 32 bits)
was being returned instead. This caused the function to return
failure for cases where it had actually succeed because when
a type (unsigned int) is converted to a narrower type (char),
the excess bits on the left are discarded. Thus if the 8
rightmost bits are zero, the return value will be 0 (failure).
The solution is to simply return true (1) only if the number of
registered table is greater than zero and false (0) otherwise.
Problem was an unclear error message since it could suggest that
MyISAM did not support INSERT DELAYED.
Changed the error message to say that DELAYED is not supported by the
table, instead of the table's storage engine.
The confusion is that a partitioned table is in somewhat sense using
the partitioning storage engine, which in turn uses the ordinary
storage engine. By saying that the table does not support DELAYED we
do not give any extra informantion about the storage engine or if it
is partitioned.
The Diagnostic_area caused an assertion failure in debug mode when
the disk was full.
By setting the internal error handler to ignore errors caused by
underlying logging methods, the error is avoided.
PREPARE", review fixes:
- make the patch follow the specification of WL#4166 and remove
the new error that was originally introduced.
Now the client never gets an error from reprepare, unless it failed.
I.e. even if the statement at hand returns a completely different
result set, this is not considered a server error.
The C API library, that can not handle this situation, was modified to
return a client error.
Added additional test coverage.
first row or fails with an error:
ERROR 1022 (23000): Can't write; duplicate key in table ''
The server uses intermediate temporary table to store updated
row data. The first column of this table contains rowid.
Current server implementation doesn't reset NULL flag of that
column even if the server fills a column with rowid.
To keep each rowid unique, there is an unique index.
An insertion into an unique index takes into account NULL
flag of key value and ignores real data if NULL flag is set.
So, insertion of actually different rowids may lead to two
kind of problems. Visible effect of each of these problems
depends on an initial engine type of temporary table:
1. If multiupdate initially creates temporary table as
a MyISAM table (a table contains blob columns, and the
create_tmp_table function assumes, that this table is
large), it inserts only one single row and updates
only rows with one corresponding rowid. Other rows are
silently ignored.
2. If multiupdate initially creates MEMORY temporary
table, fills it with data and reaches size limit for
MEMORY tables (max_heap_table_size), multiupdate
converts MEMORY table into MyISAM table and fails
with an error:
ERROR 1022 (23000): Can't write; duplicate key in table ''
Multiupdate has been fixed to update the NULL flag of
temporary table rowid columns.
with dependent subqueries
An IN subquery is executed on EXPLAIN when it's not correlated.
If the subquery required a temporary table for its execution
not all the internal structures were restored from pointing to
the items of the temporary table to point back to the items of
the subquery.
Fixed by restoring the ref array when a temp tables were used in
executing the IN subquery during EXPLAIN EXTENDED.
slave
The stored-routine code took the contents of the (lowest) parser
and copied it directly to the binlog, which causes problems if there
is a special case of interpretation at the parser level -- which
there is, in the "/*!VER */" comments. The trailing "*/" caused
errors on the slave, naturally.
Now, since by that point we have /properly/ created parse-tree (as
the rest of the server should do!) for the stored-routine CREATE, we
can construct a perfect statement from that information, instead of
writing uncertain information from an unknown parser state.
Fortunately, there's already a function nearby that does exactly
that.
---
Update for Bug#36570. Qualify routine names with db name when
writing to the binlog ONLY if the source text is qualified.
slave
The stored-routine code took the contents of the (lowest) parser
and copied it directly to the binlog, which causes problems if there
is a special case of interpretation at the parser level -- which
there is, in the "/*!VER */" comments. The trailing "*/" caused
errors on the slave, naturally.
Now, since by that point we have /properly/ created parse-tree (as
the rest of the server should do!) for the stored-routine CREATE, we
can construct a perfect statement from that information, instead of
writing uncertain information from an unknown parser state.
Fortunately, there's already a function nearby that does exactly
that.
with previous rows.
The WHERE clause containing expression:
CONCAT(empty_field1, empty_field2, ..., 'literal constant', ...)
REGEXP 'regular expression'
may return wrong matches.
Optimization of the CONCAT function has been fixed.
subselects into account
It is forbidden to use the SELECT INTO construction inside UNION statements
unless on the last SELECT of the union. The parser records whether it
has seen INTO or not when parsing a UNION statement. But if the INTO was
legally used in an outer query, an error is thrown if UNION is seen in a
subquery. Fixed in 5.0 by remembering the nesting level of INTO tokens and
mitigate the error unless it collides with the UNION.
When flushing tables, there were a slight chance that the flush was occuring
between processing of two table map events. Since the tables are opened
one by one, it might result in that the tables were not valid and that sub-
sequent locking of tables would cause the slave to crash.
The problem is solved by opening and locking all tables at once using
simple_open_n_lock_tables(). Also, the patch contain a change to open_tables()
so that pre-locking only takes place when the trg_event_map is not zero, which
was not the case before (this caused the lock to be placed in thd->locked_tables
instead of thd->lock since the assumption was that triggers would be called
later and therefore the tables should be pre-locked).
