------------------------------------------------------------
revno: 2476.657.208
committer: anozdrin/alik@station.
timestamp: Tue 2007-12-04 17:22:53 +0300
message:
Remove rpl_probe, enable_rpl_parse and disable_rpl_parse commands
from mysqltest, the corresponding funtctions have been removed from
MySQL C API
------------------------------------------------------------
revno: 2476.981.1
committer: msvensson@pilot.mysql.com
timestamp: Mon 2007-11-26 19:03:23 +0100
message:
Bug#31952 Remove undocumented mysql_rpl_* functions.
- Functions removed + variables in st_mysql and st_mysql_options
renamed to "unused".
- Code updated to work without those functions and variables
revno: 2630.22.41
committer: Alexander Nozdrin <alik@mysql.com>
branch nick: 6.0-rt-bug39255
timestamp: Thu 2008-10-16 16:39:30 +0400
message:
A patch for Bug#39255: Stored procedures: crash if function
references nonexistent table.
The problem is not reproduced in 6.0. Adding a test case.
redefining trigger
The 'table->auto_increment_field_not_null' flag is only valid within
processing of a single row, and should be set to FALSE before
navigating to the next row, or exiting the operation.
This bug was caused by an SQL error occuring while executing a trigger
after the flag had been set, so the normal resetting was bypassed.
The table object was then returned to the table share's cache in
a dirty condition. When the table object was reused, an assert
caught that the flag was set.
This patch explicitly clears the flag on error/abort.
Backported from mysql-6.0-codebase revid: 2617.52.1
The fix for Bug #38124 introuced a bug. If the value given
for a set_var exceeded the length of the temporary buffer,
we would read behind the end of the buffer. Using
c_ptr_safe(), instead of c_ptr(), ensures that we won't
read beyond the buffer limit
mysql-6.0-codebase revid: 2617.44.1
get_table_share, drop_open_table
In the partition handler code, LOCK_open and share->LOCK_ha_data
are acquired in the wrong order in certain cases. When doing a
multi-row INSERT (i.e a INSERT..SELECT) in a table with auto-
increment column(s). the increments must be in a monotonically
continuous increasing sequence (i.e it can't have "holes"). To
achieve this, a lock is held for the duration of the operation.
share->LOCK_ha_data was used for this purpose.
Whenever there was a need to open a view _during_ the operation
(views are not currently pre-opened the way tables are), and
LOCK_open was grabbed, a deadlock could occur. share->LOCK_ha_data
is other places used _while_ holding LOCK_open.
A new mutex was introduced in the HA_DATA_PARTITION structure,
for exclusive use of the autoincrement data fields, so we don't
need to overload the use of LOCK_ha_data here.
A module test case has not been supplied, since the problem occurs
as a result of a race condition, and testing for this condition
is thus not deterministic. Testing for it could be done by
setting up a test case as described in the bug report.
When assigning the new string value to the variable, the
Item::str_value member was used. This is not according to
the protocol. str_value is an internal member used for
temporary assignments, and is not consistently set for all
string operations. It is set for constant strings, so it would
work in these cases, but not for string functions (concat,
substr, etc.)
The correct approach is to use Item::val_str(..) to evaluate
and retrieve the string.
Backport from 6.0-codebase
6.0-codebase revno: 2617.31.17
Fix a regression that crept in when downporting Windows improvements.
Instead of a shutdown thread, another thread that handledsocket connection was created.
Temporary tables may set join->group to 0 even though there is
grouping. Also need to test if sum_func_count>0 when JOIN::exec()
decides whether to present results in a grouped manner.
----------------------------------------------------------
revno: 2630.28.1
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Thu 2008-10-23 15:23:44 +0400
message:
Bug#32738 "mysqld: Two slow log option/variable descriptions are
inaccurate"
Update option description per suggestion from the documentation team.
Bug #47274 assert in open_table on CREATE TABLE <already existing>
The problem was an assertion during execution of CREATE TABLES.
This assertion would occur if INSERT DELAYED or REPLACE DELAYED
were used to update a table containing an AUTO_INCREMENT column
and if the inserted row had a user-supplied value for that column.
Any CREATE TABLE statement (including CREATE TABLE SELECT and
CREATE TABLE LIKE) trying to create the same table and
which followed the INSERT/REPLACED would cause the assertion.
The problem was only noticeable on debug builds of the server
and not present in the mysql-5.1 tree.
The cause of the problem was that the code for delayed insert did
not properly reset the TABLE->auto_increment_if_null flag after
The flag is used to indicate that a non-null value of an auto_increment field
has been provided by the user or retrieved from a current record.
Open_tables() contains an assertion that tests this flag, and this
was triggered by CREATE TABLE.
This patch fixes the problem by resetting the auto_increment_if_null
field to FALSE once INSERT/REPLACE DELAYED has updated the table,
similar to what is done already for regular INSERT statements.
Test case added to delayed.test.
mysql-test/r/loadxml.result
mysql-test/t/loadxml.test
Fixing non-deterministic test results
sql/sql_yacc.yy
Initializing fname_first using get_tok_end() instead of get_ptr().
The latter is grammar-dependant. The former is not.
----------------------------------------------------------
revno: 2630.22.8
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-runtime
timestamp: Sun 2008-08-10 18:49:52 +0400
message:
Get rid of typedef struct for the most commonly used types:
TABLE, TABLE_SHARE, LEX. This simplifies use of tags
and forward declarations.
columns without where/group
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.
Difficult to debug due to lacking report
This does not solve the real issue, but extracts server log when it happens
Forst commit was incomplete, didn't cover all cases
Use ev_offset instead of 1 as the packet header offset when getting
log position from events for heartbeat
call reset_transmit_packet before calling send_heartbeat_event
