For GCov builds, if the server crashes, the normal exit handler for writing
coverage information is not executed due to the abnormal termination.
Fix this by explicitly calling the __gcov_flush function in our crash handler.
into labbari.dsl.inet.fi:/home/my/bk/mysql-5.0-marvel
libmysql/libmysql.c:
Auto merged
mysql-test/r/innodb_mysql.result:
Manual merge from main 5.1 to 5.1-marvel.
mysql-test/t/innodb_mysql.test:
Manual merge from main 5.1 to 5.1-marvel.
The SELECT INTO OUTFILE FIELDS ENCLOSED BY digit or minus sign,
followed by the same LOAD DATA INFILE statement, used wrond encoding
of non-string fields contained the enclosed character in their text
representation.
Example:
SELECT 15, 9 INTO OUTFILE 'text' FIELDS ENCLOSED BY '5';
Old encoded result in the text file:
5155 595
^ was decoded as the 1st enclosing character of the 2nd field;
^ was skipped as garbage;
^ ^ was decoded as a pair of englosing characters of the 1st field;
^ was decoded as traling space of the first field;
^^ was decoded as a doubled enclosed character.
New encoded result in the text file:
51\55 595
^ ^ pair of enclosing characters of the 1st field;
^^ escaped enclosed character.
sql/sql_class.h:
Fixed bug #29442.
The NUMERIC_CHARS macro constant has been defined to enumerate
all possible characters of a numeric value text representation.
The select_export::is_unsafe_field_sep boolean flag has been added
to apply the encoding algorithm to non-string values when it is
necessary.
sql/sql_class.cc:
Fixed bug #29442.
The select_export::send_data method has been modified to encode text
representation of fields of all data types like string fields.
mysql-test/t/loaddata.test:
Updated test case for bug #29442.
mysql-test/r/loaddata.result:
Updated test case for bug #29442.
AsText() needs to know the maximum number of
characters a IEEE double precision value can
occupy to make sure there's enough buffer space.
The number was too small to hold all possible
values and this caused buffer overruns.
Fixed by correcting the calculation of the
maximum digits in a string representation of an
IEEE double precision value as printed by
String::qs_append(double).
mysql-test/r/gis.result:
Bug #29166: test case
mysql-test/t/gis.test:
Bug #29166: test case
sql/spatial.cc:
Bug #29166: correct calculation of the maximum digits in
a string representation of a double
This bug may manifest itself for select queries over a multi-table view
that includes an ORDER BY clause in its definition. If the select list of
the query contains references to the same view column with different
aliases the names of the columns in the result output will be nevertheless
the same, coinciding with one of the alias.
The bug happened because the method Item_ref::get_tmp_table_item that
was inherited by the class Item_direct_view_ref ignored the fact that
the name of the view column reference must be inherited by the fields
of the temporary table that was created in order to get the result rows
sorted.
mysql-test/r/view.result:
Added a test case for bug #29392.
mysql-test/t/view.test:
Added a test case for bug #29392.
sql/item.h:
Fixed bug #29392.
This bug may manifest itself for select queries over a multi-table view
that includes an ORDER BY clause in its definition. If the select list of
the query contains references to the same view column with different
aliases the names of the columns in the result output will be nevertheless
the same, coinciding with one of the alias.
The bug happened because the method Item_ref::get_tmp_table_item that
was inherited by the class Item_direct_view_ref ignored the fact that
the name of the view column reference must be inherited by the fields
of the temporary table that was created in order to get the result rows
sorted.
Fixed by providing a proper implementation of the get_tmp_table_item
method for the Item_direct_view_ref class.
into gleb.loc:/home/uchum/work/bk/5.0-opt
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_load.cc:
Auto merged
mysql-test/r/loaddata.result:
Merge with 4.1-opt.
mysql-test/t/loaddata.test:
Merge with 4.1-opt.
The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement
encoded the 'r' string to a 4 byte string of value x'725c7272'
(sequence of 4 characters: r\rr).
The LOAD DATA statement decoded this string to a 1 byte string of
value x'0d' (ASCII Carriage Return character) instead of the original
'r' character.
The same error also happened with the FIELDS ENCLOSED BY clause
followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'.
NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE
recognises 2-byte input sequences like \n, \t, \r and \Z in addition
to documented 2-byte sequences: \0 and \N. This feature should be
documented (here backspace character is a default ESCAPED BY character,
in the real-life example it may be any ESCAPED BY character).
NOTE 2, changed behaviour:
Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY'
clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters
encodes this special character itself by doubling it ('r' --> 'rr'),
not by prepending it with an escape character.
sql/sql_class.h:
Fixed bug #29294.
The ESCAPE_CHARS macro constant is defined to enumerate
symbolic names of espace-sequences like '\n', '\t' etc.
The select_export::is_ambiguous_field_sep field has been added
to distinguish special values of the field_sep field from
another values (see ESCAPE_CHARS).
sql/sql_class.cc:
Fixed bug #29294.
The select_export::send_data method has been modified to
encode special values of the field_sep field by
doubling of those values instead of prepending them with a
value of the escape_char field.
Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
now produces the 'rr' output string instead of x'5c72'
(i.e. instead of sequence of 2 bytes: \ and r).
sql/sql_load.cc:
Fixed bug #29294.
Added commentary for the READ_INFO::unescape method.
mysql-test/t/loaddata.test:
Updated test case for bug #29294.
mysql-test/r/loaddata.result:
Updated test case for bug #29294.
asserts debug binary
We can't reliably check if the binary log is opened without
acquiring its mutex.
Fixed by removing this check.
sql/log.cc:
Bug #28983:
can't reliably check if bin_log is open outside of its mutex
This bug may manifest itself not only with the queries for which
the index-merge access method is chosen. It also may display
itself for queries with DISTINCT.
The bug was in how the Unique::get method used the merge_buffers
function. To compare elements in the the queue employed by
merge_buffers() it must use the buffpek_compare function rather
than the function for binary comparison.
mysql-test/r/innodb_mysql.result:
Added a test case for bug #25798.
mysql-test/t/innodb_mysql.test:
Added a test case for bug #25798.
sql/filesort.cc:
Fixed bug #25798.
The function merge_buffers() when called from the Uniques::get method
must use function buffpek_compare to compare elements in the queue it
employs. The pointer to buffpek_compare and the info for the function
that compares sorted records are passed to merge_buffers through certain
designated fields of the SORTPARAM structure.
sql/sql_sort.h:
Fixed bug #25798.
Added fields to the SORTPARAM structure to be used in the function
merge_buffers when called by the Uniques::get method.
sql/uniques.cc:
Fixed bug 25798.
The function merge_buffers() when called from the Uniques::get method
must use function buffpek_compare to compare elements in the queue it
employes.
into olga.mysql.com:/home/igor/mysql-5.0-opt
mysql-test/r/type_enum.result:
Auto merged
mysql-test/t/type_enum.test:
Auto merged
sql/field_conv.cc:
SCCS merged
When a UNION statement forced conversion of an UTF8
charset value to a binary charset value, the byte
length of the result values was truncated to the
CHAR_LENGTH of the original UTF8 value.
sql/item.cc:
Fixed bug #29205.
The calculation of data length was modified in
the Item_type_holder::join_types method to take into
account possible conversion of a multibyte charset
value to a binary charset value, when each
multibyte character is converted into a sequence
of bytes (not to a single byte of binary charset).
mysql-test/t/ctype_utf8.test:
Updated test case for bug #29205.
mysql-test/r/ctype_utf8.result:
Updated test case for bug #29205.
query / no aggregate of subquery
The optimizer counts the aggregate functions that
appear as top level expressions (in all_fields) in
the current subquery. Later it makes a list of these
that it uses to actually execute the aggregates in
end_send_group().
That count is used in several places as a flag whether
there are aggregates functions.
While collecting the above info it must not consider
aggregates that are not aggregated in the current
context. It must treat them as normal expressions
instead. Not doing that leads to incorrect data about
the query, e.g. running a query that actually has no
aggregate functions as if it has some (and hence is
expected to return only one row).
Fixed by ignoring the aggregates that are not aggregated
in the current context.
One other smaller omission discovered and fixed in the
process : the place of aggregation was not calculated for
user defined functions. Fixed by calling
Item_sum::init_sum_func_check() and
Item_sum::check_sum_func() as it's done for the rest of
the aggregate functions.
mysql-test/r/subselect.result:
Bug #27333: test case
mysql-test/t/subselect.test:
Bug #27333: test case
sql/item_subselect.cc:
Bug#27333: need select_lex to filter out
aggregates that are not aggregated in
the current select.
sql/item_sum.cc:
Bug#27333: need select_lex to filter out
aggregates that are not aggregated in
the current select.
sql/item_sum.h:
Bug#27333: calculate the place of
aggregation for user defined functions.
sql/sql_select.cc:
Bug#27333: When counting the aggregated functions
and collecting a list of them we must not consider
the aggregates that are not aggregated in the local
context as "local" : i.e. we must treat them as
normal functions and not add them to the aggregate
functions list.
sql/sql_select.h:
Bug#27333: need select_lex to filter out
aggregates that are not aggregated in
the current select.
"Federared Transactions Failure"
Bug occurs when the user performs an operation which inserts more than
one row into the federated table and the federated table references a
remote table stored within a transactional storage engine. When the
insert operation for any one row in the statement fails due to
constraint violation, the federated engine is unable to perform
statement rollback and so the remote table contains a partial commit.
The user would expect a statement to perform the same so a statement
rollback is expected.
This bug was fixed by implementing bulk-insert handling into the
federated storage engine. This will relieve the bug for most common
situations by enabling the generation of a multi-row insert into the
remote table and thus permitting the remote table to perform
statement rollback when neccessary.
The multi-row insert is limited to the maximum packet size between
servers and should the size overflow, more than one insert statement
will be sent and this bug will reappear. Multi-row insert is disabled
when an "INSERT...ON DUPLICATE KEY UPDATE" is being performed.
The bulk-insert handling will offer a significant performance boost
when inserting a large number of small rows.
This patch builds on Bug29019 and Bug25511
sql/ha_federated.cc:
bug25513
new member methods:
start_bulk_insert() - initializes memory for bulk insert
end_bulk_insert() - sends any remaining bulk insert and frees memory
append_stmt_insert() - create the INSERT statement
sql/ha_federated.h:
bug25513
new member value:
bulk_insert
new member methods:
start_bulk_insert(), end_bulk_insert(), append_stmt_insert()
make member methods private:
read_next(), index_read_idx_with_result_set()
mysql-test/r/federated_innodb.result:
New BitKeeper file ``mysql-test/r/federated_innodb.result''
mysql-test/t/federated_innodb-slave.opt:
New BitKeeper file ``mysql-test/t/federated_innodb-slave.opt''
mysql-test/t/federated_innodb.test:
New BitKeeper file ``mysql-test/t/federated_innodb.test''
"Federated INSERT failures"
Federated does not correctly handle "INSERT...ON DUPLICATE KEY UPDATE"
However, implementing such support is not reasonably possible without
increasing complexity of the storage engine: checking that constraints
on remote server match local server and parsing error messages.
This patch causes 'ON DUPLICATE KEY' to fail with ER_DUP_KEY message
if a conflict occurs and not to fail silently.
include/my_base.h:
bug25511
new storage engine hint: HA_EXTRA_INSERT_WITH_UPDATE
mysql-test/r/federated.result:
test for bug25511
mysql-test/t/federated.test:
test for bug25511
sql/ha_federated.cc:
bug25511
implement support for handling HA_EXTRA_INSERT_WITH_UPDATE hint
sql/ha_federated.h:
bug25511
new property: insert_dup_update
sql/sql_insert.cc:
bug25511
implement support for HA_EXTRA_INSERT_WITH_UPDATE
When checking duplicates flag, if it is DUP_UPDATE, send hint
to the storage engine.
SHOW CREATE TABLE or SELECT FROM I_S.
Actually, the bug discovers two problems:
- the original query is not preserved properly. This is the problem
of BUG#16291;
- the resultset of SHOW CREATE TABLE statement is binary.
This patch fixes the second problem for the 5.0.
Both problems will be fixed in 5.1.
mysql-test/r/show_check.result:
Update result file.
mysql-test/t/show_check.test:
Provide test case for BUG#10491.
sql/item.h:
Use utf8_general_ci instead of binary collation by default,
because for views and base tables utf8 is the character set
in which their definition is stored. For system constants
it's the default character set, and for other objects
(routines, triggers), no character set is stored, and
therefore no character set is known, so returning utf8
is just as good as any non-binary character set.
This latter problem is fixed in 5.1 by 16291. In 5.1
we will return the "real" character set.
"REPLACE/INSERT IGNORE/UPDATE IGNORE doesn't work"
Federated does not record neccessary HA_EXTRA flags in order to
support REPLACE/INSERT IGNORE/UPDATE IGNORE.
Implement ::extra() to capture flags neccessary for functionality.
New function append_ident() to better escape identifiers consistantly.
mysql-test/r/federated.result:
test for bug29019
mysql-test/t/federated.test:
test for bug29019
sql/ha_federated.cc:
Bug29019
Federated does not record neccessary HA_EXTRA flags in order to
support REPLACE/INSERT IGNORE/UPDATE IGNORE.
Implement ::extra() to capture flags neccessary for functionality.
New function append_ident() to better escape identifiers consistantly.
sql/ha_federated.h:
bug29019
add 2 member values to ha_federated class
ignore_duplicates and replace_duplicates.
add 1 member method to ha_federated class
extra()
Thanks to Martin Friebe for finding and submitting a fix for this bug!
A table with maximum number of key segments and maximum length key name
would have a corrupted .frm file, due to an incorrect calculation of the
complete key length. Now the key length is computed correctly (I hope) :-)
MyISAM would reject a table with the maximum number of keys and the maximum
number of key segments in all keys. It would allow one less than this total
maximum. Now MyISAM accepts a table defined with the maximum. (This is a
very minor issue.)
myisam/mi_open.c:
Bug #26642: change >= to > in a comparison (i.e., error
only if key_parts_in_table really is greater than
MAX_KEY * MAX_KEY_SEG)
mysql-test/r/create.result:
Bug #26642: test case
mysql-test/t/create.test:
Bug #26642: test case
sql/table.cc:
Bug #26642: In create_frm(), fix formula for key_length;
it was too small by (keys * 2) bytes
CHECK TABLE against ARCHIVE table may falsely report table corruption,
or cause server crash.
Fixed by using proper buffer for CHECK TABLE.
Affects both 5.0 and 5.1.
mysql-test/r/archive.result:
A test case for BUG#28916.
mysql-test/t/archive.test:
A test case for BUG#28916.
sql/ha_archive.cc:
We call Field::get_length() from get_row(). Field::get_length() assumes
that the row was read into table->record[0] buffer, which is not the
case when we check a table. As a result we get wrongly initialized
blob length.
Use table->record[0] as record buffer for check table instead.
Sometimes special 0 ENUM values was ALTERed to normal
empty string ENUM values.
Special 0 ENUM value has the same string representation
as normal ENUM value defined as '' (empty string).
The do_field_string function was used to convert
ENUM data at an ALTER TABLE request, but this
function doesn't care about numerical "indices" of
ENUM values, i.e. do_field_string doesn't distinguish
a special 0 value from an empty string value.
A new copy function called do_field_enum has been added to
copy special 0 ENUM values without conversion to an empty
string.
sql/field_conv.cc:
Fixed bug #29251.
The Copy_field::get_copy_func method has been modified to
return a pointer to the do_field_enum function if a conversion
between two columns of incompatible enum types is required.
The do_field_enum function has been added for the correct
conversion of special 0 enum values.
mysql-test/t/type_enum.test:
Updated test case for bug #29251.
mysql-test/r/type_enum.result:
Updated test case for bug #29251.
LOCK TABLES takes a list of tables to lock. It may lock several
tables successfully and then encounter a tables that it can't lock,
e.g. because it's locked. In such case it needs to undo the locks on
the already locked tables. And it does that. But it has also notified
the relevant table storage engine handlers that they should lock.
The only reliable way to ensure that the table handlers will give up
their locks is to end the transaction. This is what UNLOCK TABLE
does : it ends the transaction if there were locked tables by LOCK
tables.
It is possible to end the transaction when the lock fails in
LOCK TABLES because LOCK TABLES ends the transaction at its start
already.
Fixed by ending (again) the transaction when LOCK TABLES fails to
lock a table.
mysql-test/r/innodb_mysql.result:
Bug #29154: test case
mysql-test/t/innodb_mysql.test:
Bug #29154: test case
sql/sql_parse.cc:
Bug #29154: end the trasaction at a failing
LOCK TABLES so the handler can free its locks.
Max compressed file size was calculated incorretly causing server
crash on INSERT.
With this patch we use proper max file size provided by zlib.
Affects 5.0 only.
sql/ha_archive.cc:
When calculating max compressed file size, use the real offset size
that is provided by zlib, instead of sizeof(z_off_t), which may be
different from actual offset size.
When we're about to write and the data file is almost full flush gzio
buffer to get accurate real file size.
mysql-test/r/archive-big.result:
New BitKeeper file ``mysql-test/r/archive-big.result''
mysql-test/t/archive-big.test:
New BitKeeper file ``mysql-test/t/archive-big.test''
the loose scan optimization for grouping queries was applied returned
a wrong result set when the query was used with the SQL_BIG_RESULT
option.
The SQL_BIG_RESULT option forces to use sorting algorithm for grouping
queries instead of employing a suitable index. The current loose scan
optimization is applied only for one table queries when the suitable
index is covering. It does not make sense to use sort algorithm in this
case. However the create_sort_index function does not take into account
the possible choice of the loose scan to implement the DISTINCT operator
which makes sorting unnecessary. Moreover the current implementation of
the loose scan for queries with distinct assumes that sorting will
never happen. Thus in this case create_sort_index should not call
the function filesort.
mysql-test/r/group_min_max.result:
Added a test case for bug #25602.
mysql-test/t/group_min_max.test:
Added a test case for bug #25602.
