numbers into char fields" and bug #12860 "Difference in zero padding of
exponent between Unix and Windows"
Rewrote the code that determines what 'precision' argument should be
passed to sprintf() to fit the string representation of the input number
into the field.
We get finer control over conversion by pre-calculating the exponent, so
we are able to determine which conversion format, 'e' or 'f', will be
used by sprintf().
We also remove the leading zero from the exponent on Windows to make it
compatible with the sprintf() output on other platforms.
PS-protocol data is stored in different format - the MYSQL_RECORDS->data
contains the link to the record content, not to array of the links to
the field's contents. So we have to handle it separately for
embedded-server query cache.
Bug#31030 rpl000015.test fails if $MYSQL_TCP_PORT != 3306
Note:
This bug does not occur in MySQL 5.0 and up, because
ChangeSet 1.2328.2.1 2006/11/27 for MySQL 5.0 prevents this.
The 5.0 fix uses the environment variable DEFAULT_MASTER_PORT
which is set by mysql-test-run.pl.
mysql-test-run.pl in 4.1 does not set this variable.
There are two alternatives:
1) Backport the 5.0 fix for this test including modifications
to mysql-test-run.pl and mysql-test-run-shell.
This is a not acceptable impact on an old MySQL version.
2) Fix the problem different than in 5.0 like in the current
ChangeSet + do not apply these changes when upmerging to 5.0
1. A bad error message was given when a MERGE table with an
InnoDB child table was tried to use.
2. After selecting from a correct MERGE table and then altering
one of the children to InnoDB, incorrect results were returned.
These bugs have been fixed with the patch for bug 26379 (Combination
of FLUSH TABLE and REPAIR TABLE corrupts a MERGE table).
For verification, I added the test case from the bug report.
filesort() uses file->estimate_rows_upper_bound() call to allocate
internal buffers. If this function returns a value smaller than
a number of row that will be returned later in find_all_keys(),
that can cause server crash.
Fixed by implementing ha_federated::estimate_rows_upper_bound() to
return maximum possible number of rows.
Present estimation for FEDERATED always returns 0 if the linked to the VIEW.
Parser rejects valid INTERVAL() expressions when associated with
arithmetic operators. The problem is the way in which the expression
and interval grammar rules were organized caused shift/reduce conflicts.
The solution is to tweak the interval rules to avoid shift/reduce
conflicts by removing the broken interval_expr rule and explicitly
specify it's content where necessary.
Original fix by Davi Arnaut, revised and improved rules by Marc Alff
The following clarification should be made in The Manual:
Standard SQL is quite clear that, if new columns are added
to a table after a view on that table is created with
"select *", the new columns will not become part of the view.
In all cases, the view definition (view structure) is frozen
at CREATE time, so changes to the underlying tables do not
affect the view structure.
Default values of variables were not subject to upper/lower bounds
and step, while setting variables was. Bounds and step are also
applied to defaults now; defaults are corrected quietly, values
given by the user are corrected, and a correction-warning is thrown
as needed. Lastly, very large values could wrap around, starting
from 0 again. They are bounded at the maximum value for the
respective data-type now if no lower maximum is specified in the
variable's definition.
This bug is actually two bugs in one, one of which is CREATE TRIGGER under
LOCK TABLES and the other is CREATE TRIGGER under LOCK TABLES simultaneous
to a FLUSH TABLES WITH READ LOCK (global read lock). Both situations could
lead to a server crash or deadlock.
The first problem arises from the fact that when under LOCK TABLES, if the
table is in the set of locked tables, the table is already open and it doesn't
need to be reopened (not a placeholder). Also in this case, if the table is
not write locked, a exclusive lock can't be acquired because of a possible
deadlock with another thread also holding a (read) lock on the table. The
second issue arises from the fact that one should never wait for a global
read lock if it's holding any locked tables, because the global read lock
is waiting for these tables and this leads to a circular wait deadlock.
The solution for the first case is to check if the table is write locked
and upgraded the write lock to a exclusive lock and fail otherwise for non
write locked tables. Grabbin the exclusive lock in this case also means
to ensure that the table is opened only by the calling thread. The second
issue is partly fixed by not waiting for the global read lock if the thread
is holding any locked tables.
The second issue is only partly addressed in this patch because it turned
out to be much wider and also affects other DDL statements. Reported as
Bug#32395
