into  whirlpool.hristov.com:/work/mysql-5.1-runtime

Disabled events weren't removed from the memory queue after the scheduler has been
re-enabled. After recalculation of next execution time of an event, it might get disabled.

into  buzz.(none):/home/davi/mysql-5.1-runtime

concurrent inserts.

into  quad.:/mnt/raid/alik/MySQL/devel/bug-30217/5.1-rt-bug30217

between 5.0 and 5.1.
  
The problem was that in the patch for Bug#11986 it was decided
to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
This approach however turned out to be quite difficult to implement
properly. The main problem is to preserve the same IS-output after
dump/restore.
  
So, the fix is to rollback to the previous functionality, but also
to fix it to support multi-character-set-queries properly. The idea
is to generate INFORMATION_SCHEMA-query from the item-tree after
parsing view declaration. The IS-query should:
  - be completely in UTF8;
  - not contain character set introducers.
  
For more information, see WL4052.

into  buzz.(none):/home/davi/mysql-5.1-runtime

The problem is that CREATE VIEW statements inside prepared statements
weren't being expanded during the prepare phase, which leads to objects
not being allocated in the appropriate memory arenas.

The solution is to perform the validation of CREATE VIEW statements
during the prepare phase of a prepared statement. The validation
during the prepare phase assures that transformations of the parsed
tree will use the permanent arena of the prepared statement.

sending SIGHUP.

There were two problems:
  - after some recent fix, the server started to crash after
    receiving SIGHUP. That happened because LEX of new THD-object
    was not properly initialized.
  - user-specified log options were ignored when logs were reopened.

The fix is to 1) initialize LEX and 2) take user-specified options
into account.

There is no test case in this CS, because our test suite does not
support sending SIGHUP to the server.

into  quad.:/mnt/raid/alik/MySQL/devel/bug-34337/5.1-rt-bug34337

a table name.
  
The problem was that fill_defined_view_parts() did not return
an error if a table is going to be altered. That happened if
the table was already in the table cache. In that case,
open_table() returned non-NULL value (valid TABLE-instance from
the cache).
  
The fix is to ensure that an error is thrown even if the table
is in the cache.

(This is a backport of the original patch for 5.1)

into  buzz.(none):/home/davi/mysql-5.1-runtime

by patch for bug 32265 .

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

The problem is that when a stored procedure is being parsed for
the first execution, the body is copied to a temporary buffer
which is disregarded sometime after the statement is parsed.
And during this parsing phase, the rule for CREATE VIEW was
holding a reference to the string being parsed for use during
the execution of the CREATE VIEW statement, leading to invalid
memory access later.

The solution is to allocate and copy the SELECT of a CREATE
VIEW statement using the thread memory root, which is set to
the permanent arena of the stored procedure. 

Executing a prepared statement associated with a materialized
cursor yields to the client a metadata packet with wrong table
and database names. The problem was occurring because the server
was sending the the name of the temporary table used by the cursor
instead of the table name of the original table. The same problem
occurs when selecting from views, in which case the table name was
being sent and not the name of the view.
  
The solution is to fill the list item from the temporary table but
preserving the table and database names of the original fields. This
is achieved by tweaking the Select_materialize to accept a pointer to
the Materialized_cursor class which contains the item list to be filled.

a table name.

The problem was that fill_defined_view_parts() did not return
an error if a table is going to be altered. That happened if
the table was already in the table cache. In that case,
open_table() returned non-NULL value (valid TABLE-instance from
the cache).

The fix is to ensure that an error is thrown even if the table
is in the cache.

into  dipika.(none):/opt/local/work/mysql-5.1-runtime

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

does not send it to the client.

into  dipika.(none):/opt/local/work/mysql-5.1-2pc-opt-merge-push

a SELECT doesn't cause ROLLBACK of statem".

The idea of the fix is to ensure that we always commit the current
statement at the end of dispatch_command(). In order to not issue
redundant disc syncs, an optimization of the two-phase commit
protocol is implemented to bypass the two phase commit if
the transaction is read-only.

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

FK definition.

failing on heavily loaded systems.

two timestamp fields.
  
The actual problem here was that CREATE TABLE allowed zero
date as a default value for a TIMESTAMP column in NO_ZERO_DATE mode.
  
The thing is that for TIMESTAMP date type specific rule is applied:
  column_name TIMESTAMP == column_name TIMESTAMP DEFAULT 0
whever for any other date data type
  column_name TYPE == column_name TYPE DEFAULT NULL
  
The fix is to raise an error when we're in NO_ZERO_DATE mode and
there is TIMESTAMP column w/o default value.

BUG#24387, which is closed since long.