1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-01 03:47:19 +03:00

5.1 version of a fix and test cases for bugs:

Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a 
growing key length" (this bug is not fixed in 5.0)

Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).

In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
  
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc 
for drop_it.remove() and similar patterns to find evidence.
  
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement. 
  
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
  
The problem of crashing bug 22060 stemmed from the fact that the above 
metnioned functions were not only modifying HA_CREATE_INFO structure 
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
   
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.

Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.
This commit is contained in:
kostja@vajra.(none)
2007-05-28 15:30:01 +04:00
parent 7db7a83f94
commit c759487769
17 changed files with 1602 additions and 1064 deletions

View File

@ -1,3 +1,5 @@
#ifndef INCLUDES_MYSQL_SQL_LIST_H
#define INCLUDES_MYSQL_SQL_LIST_H
/* Copyright (C) 2000-2003 MySQL AB
This program is free software; you can redistribute it and/or modify
@ -63,21 +65,24 @@ public:
pointer.
*/
class list_node :public Sql_alloc
/**
list_node - a node of a single-linked list.
@note We never call a destructor for instances of this class.
*/
struct list_node :public Sql_alloc
{
public:
list_node *next;
void *info;
list_node(void *info_par,list_node *next_par)
:next(next_par),info(info_par)
{}
{}
list_node() /* For end_of_list */
{
info=0;
next= this;
}
friend class base_list;
friend class base_list_iterator;
{
info= 0;
next= this;
}
};
@ -93,12 +98,28 @@ public:
inline void empty() { elements=0; first= &end_of_list; last=&first;}
inline base_list() { empty(); }
/**
This is a shallow copy constructor that implicitly passes the ownership
from the source list to the new instance. The old instance is not
updated, so both objects end up sharing the same nodes. If one of
the instances then adds or removes a node, the other becomes out of
sync ('last' pointer), while still operational. Some old code uses and
relies on this behaviour. This logic is quite tricky: please do not use
it in any new code.
*/
inline base_list(const base_list &tmp) :Sql_alloc()
{
elements= tmp.elements;
first= tmp.first;
last= elements ? tmp.last : &first;
}
/**
Construct a deep copy of the argument in memory root mem_root.
The elements themselves are copied by pointer. If you also
need to copy elements by value, you should employ
list_copy_and_replace_each_value after creating a copy.
*/
base_list(const base_list &rhs, MEM_ROOT *mem_root);
inline base_list(bool error) { }
inline bool push_back(void *info)
{
@ -185,6 +206,15 @@ public:
elements+= list->elements;
}
}
/**
Swap two lists.
*/
inline void swap(base_list &rhs)
{
swap_variables(list_node *, first, rhs.first);
swap_variables(list_node **, last, rhs.last);
swap_variables(uint, elements, rhs.elements);
}
inline list_node* last_node() { return *last; }
inline list_node* first_node() { return first;}
inline void *head() { return first->info; }
@ -349,6 +379,8 @@ template <class T> class List :public base_list
public:
inline List() :base_list() {}
inline List(const List<T> &tmp) :base_list(tmp) {}
inline List(const List<T> &tmp, MEM_ROOT *mem_root) :
base_list(tmp, mem_root) {}
inline bool push_back(T *a) { return base_list::push_back(a); }
inline bool push_back(T *a, MEM_ROOT *mem_root)
{ return base_list::push_back(a, mem_root); }
@ -547,3 +579,32 @@ public:
I_List_iterator(I_List<T> &a) : base_ilist_iterator(a) {}
inline T* operator++(int) { return (T*) base_ilist_iterator::next(); }
};
/**
Make a deep copy of each list element.
@note A template function and not a template method of class List
is employed because of explicit template instantiation:
in server code there are explicit instantiations of List<T> and
an explicit instantiation of a template requires that any method
of the instantiated class used in the template can be resolved.
Evidently not all template arguments have clone() method with
the right signature.
@return You must query the error state in THD for out-of-memory
situation after calling this function.
*/
template <typename T>
inline
void
list_copy_and_replace_each_value(List<T> &list, MEM_ROOT *mem_root)
{
/* Make a deep copy of each element */
List_iterator<T> it(list);
T *el;
while ((el= it++))
it.replace(el->clone(mem_root));
}
#endif // INCLUDES_MYSQL_SQL_LIST_H