In 37553 we declared longlong results for
class Item_str_timefunc as per comments/docs,
but didn't add a method for that. And the
default just wasn't good enough for some
cases.
Changeset adds dedicated val_int() to class.
- If missing: add "disconnect <session>"
- If physical disconnect of non "default" sessions is not finished
at test end: add routine which waits till this happened
+ additional improvements
- remove superfluous files created by the test
- replace error numbers by error names
- remove trailing spaces, replace tabs by spaces
- unify writing of bugs within comments
- correct comments
- minor changes of formatting
Fixed tests:
backup
check
compress
grant
information_schema
multi_update
overflow
packet
query_cache_not_embedded
sp-threads
subselect
synchronization
timezone_grant
ORDER BY could cause a server crash
Dependent subqueries like
SELECT COUNT(*) FROM t1, t2 WHERE t2.b
IN (SELECT DISTINCT t2.b FROM t2 WHERE t2.b = t1.a)
caused a memory leak proportional to the
number of outer rows.
The make_simple_join() function has been modified to
JOIN class method to store join_tab_reexec and
table_reexec values in the parent join only
(make_simple_join of tmp_join may access these values
via 'this' pointer of the parent JOIN).
NOTE: this patch doesn't include standard test case (this is
"out of memory" bug). See bug #42037 page for test cases.
Problem: some queries using NAME_CONST(.. COLLATE ...)
lead to server crash due to failed type cast.
Fix: return the underlying item's type in case of
NAME_CONST(.. COLLATE ...) to avoid wrong casting.
Accessing well defined MERGE table may return an error
stating that the merge table is incorrectly defined. This
happens if MERGE child tables were accessed before and we
failed to open another incorrectly defined MERGE table in
this connection.
myrg_open() internally used my_errno as a variable for determining
failure, and thus could be tricked into a wrong decision by other
uses of my_errno.
With this fix we use function local boolean flag instead of my_errno
to determine failure.
functions
String::realloc() did not check whether the existing string data fits in the newly
allocated buffer for cases when reallocating a String object with external buffer
(i.e.alloced == FALSE). This could lead to memory overruns in some cases.
The original symptoms of this bug have been fixed as a consequence of other bug fixes.
Taking this time to correct some formatting, such as replacing error numbers with names.
Beginning this with 5.0
- If missing: add "disconnect <session>"
- If physical disconnect of non "default" sessions is not finished
at test end: add routine which waits till this happened
+ additional improvements like
- remove superfluous files created by the test
- replace error numbers by error names
- remove trailing spaces, replace tabs by spaces
- unify writing of bugs within comments
- correct comments
- minor changes of formatting
Modifications according to the code review are included.
Fixed tests:
grant2
grant3
lock_tables_lost_commit
mysqldump
openssl_1
outfile
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
When storing a NULL to a TIMESTAMP NOT NULL DEFAULT ...,
NULL returned from some functions threw a 'cannot be NULL error.'
NULL-returns now correctly result in the timestamp-field being
assigned its default value.
If the system time is adjusted back during a query execution
(resulting in the end time being earlier than the start time)
the code that prints to the slow query log gets confused and
prints unsigned negative numbers.
Fixed by not logging the statements that would have negative
execution time due to time shifts.
No test case since this would involve changing the system time.
messed up
"ROW(...) IN (SELECT ... FROM DUAL)" always returned TRUE.
Item_in_subselect::row_value_transformer rewrites "ROW(...)
IN SELECT" conditions into the "EXISTS (SELECT ... HAVING ...)"
form.
For a subquery from the DUAL pseudotable resulting HAVING
condition is an expression on constant values, so further
transformation with optimize_cond() eliminates this HAVING
condition and resets JOIN::having to NULL.
Then JOIN::exec treated that NULL as an always-true-HAVING
and that caused a bug.
To distinguish an optimized out "HAVING TRUE" clause from
"HAVING FALSE" we already have the JOIN::having_value flag.
However, JOIN::exec() ignored JOIN::having_value as described
above as if it always set to COND_TRUE.
The JOIN::exec method has been modified to take into account
the value of the JOIN::having_value field.
Various parts of code used different 'precision' arguments for sprintf("%g") when converting
floating point numbers to a string. This led to differences in results in some cases
depending on whether the text-based or prepared statements protocol is used for a query.
Fixed by changing arguments to sprintf("%g") to always be 15 (DBL_DIG) so that results are
consistent regardless of the protocol.
This patch will be null-merged to 6.0 as the problem does not exists there (fixed by the
patch for WL#2934).
into the 5.0.72sp1 branch.
Original changeset (in the main 5.0 branch):
> committer: Kent Boortz <kent@kent-amd64>
> branch nick: mysql-5.0-build-bug42278
> timestamp: Fri 2009-01-23 02:59:03 +0100
The problem is that the query cache was storing partial results
if the statement failed when sending the results to the client.
This could cause clients to hang when trying to read the results
from the cache as they would, for example, wait indefinitely for
a eof packet that wasn't saved.
The solution is to always discard the caching of a query that
failed to send its results to the associated client.
Views weren't sync()d the same way other structures were.
In creating the FRM for views, obey the same rules for variable
"sync_frm" as for everything else.
