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.
the wrong buffer
handler::index_next_same() did not take into account that the
internally called function key_cmp_if_same() uses the fixed
buffer table->record[0] for key comparison instead of the
buffer provided by the caller of handler::index_next_same().
Added code to temporarily redirect table->record[0] and the fields
used for the key to the record buffer provided by the caller of
handler::index_next_same().
The test case is in partition.test already.
partitioned table
Trying INSERT DELAYED on a partitioned table, that has not been
used right before, crashes the server. When a table is used for
select or update, it is kept open for some time. This period I
mean with "right before".
Information about partitioning of a table is stored in form of
a string in the .frm file. Parsing of this string requires a
correctly set up lexical analyzer (lex). The partitioning code
uses a new temporary instance of a lex. But it does still refer
to the previously active lex. The delayd insert thread does not
initialize its lex though...
Added initialization for thd->lex before open table in the delayed
thread and at all other places where it is necessary to call
lex_start() if all tables would be partitioned and need to parse
the .frm file.
The fix for bug 31148 is not correct. It does not
have a relation to the problem described in this bug.
And removing the fix will not make the bug to re-appear.
Fixed the bug #31974 by removing the fix for bug 31148
and adding a test case.
error evaluating WHERE"
DELETE with a subquery in WHERE clause would sometimes ignore subquery
evaluation error and proceed with deletion.
The fix is to check for an error after evaluation of the WHERE clause
in DELETE.
Addressed review comments.
If a stored function that contains a drop temporary table statement
is invoked by a create temporary table of the same name may cause
a server crash. The problem is that when dropping a table no check
is done to ensure that table is not being used by some outer query
(or outer statement), potentially leaving the outer query with a
reference to a stale (freed) table.
The solution is when dropping a temporary table, always check if
the table is being used by some outer statement as a temporary
table can be dropped inside stored procedures.
The check is performed by looking at the TABLE::query_id value for
temporary tables. To simplify this check and to solve a bug related
to handling of temporary tables in prelocked mode, this patch changes
the way in which this member is used to track the fact that table is
used/unused. Now we ensure that TABLE::query_id is zero for unused
temporary tables (which means that all temporary tables which were
used by a statement should be marked as free for reuse after it's
execution has been completed).
"ALTER SERVER can cause server to crash"
While retrieving values, it would erronously set the socket value
to NULL and attempt to use it in strcmp().
Ensure it is correctly set to "" so that strcmp may not crash.
The mysql_change_user command fails to properly update the database pointer
when no database is selected, leading to "use after free" errors. The same
happens on the user privilege pointer in the thread security context.
The solution is to properly reset and update the database name. Also update
the user_priv pointer so that it doesn't point to freed memory.
during udf initialization. The bug is spotted while working on Bug 12713.
If a user-defined function was used in a SELECT statement, and an
error would occur during UDF initialization, this error would not terminate
execution of the SELECT, but rather would be converted to a warning.
The fix is to use a stack buffer to store the message from udf_init instead
of private my_error() buffer.
check_user()/check_connection()/check_for_max_user_connections().
This is a pre-requisite patch for the fix for Bug#12713 "Error in a stored
function called from a SELECT doesn't cause ROLLBACK of statem"
Implement review comments.
Dropping users causes huge increase in memory usage because field values were
allocated on the server memory root for temporary usage but never deallocated.
This patch changes the target memory root to be that of the thread handler
instead since this root is cleared between each statement.
The SET PASSWORD statement is non-transactional (no explicit transaction
boundaries) in nature and hence is forbidden inside stored functions and
triggers, but it weren't being effectively forbidden.
The implemented fix is to issue a implicit commit with every SET PASSWORD
statement, effectively prohibiting these statements in stored functions
and triggers.
and convert it to a warning instead of direct manipulation with the
thread error stack.
Fix a bug in handler::print_erorr when a garbled message was
printed for HA_ERR_NO_SUCH_TABLE.
This is a pre-requisite patch for the fix for Bug#12713 Error in a stored
function called from a SELECT doesn't cause ROLLBACK of statem
