When only one row was present, the subtraction of nearly the same number
resulted in catastropic cancellation, introducing an error in the
VARIANCE calculation near 1e-15. That was sqrt()ed to get STDDEV, the
error was escallated to near 1e-8.
The simple fix of testing for a row count of 1 and forcing that to yield
0.0 is insufficient, as two rows of the same value should also have a
variance of 0.0, yet the error would be about the same.
So, this patch changes the formula that computes the VARIANCE to be one
that is not subject to catastrophic cancellation.
In addition, it now uses only (faster-than-decimal) floating point numbers
to calculate, and renders that to other types on demand.
The code that set up data to be passed to user-defined functions was very
old and analyzed the "Type" of the data that was passed into the UDF, when
it really should analyze the "return_type", which is hard-coded for simple
Items and works correctly for complex ones like functions.
---
Added test at Sergei's behest.
bugs/wls in cset's comments. The targetted BUG's or WL's identifier must be specified
the first in the comments. The referred bugs wls can be typed in same as the targeted
clickable format.
If the the target of the fix is a WL and there are some references to bugs
then the first found reference is regarded as "co-target" so that the bug's identifier
comes up on the subject line along with the WL's and commit mail will update
the bug page. The latter feature can be disarmed (if there is no need to update
the referred bug's page) with typing the first a pseudo-bug pattern (bug#0).
This paticular cset will generate subject line containing bug#0 (as it was the first
referred) whereas the old version would put in the subject line the last referred
pattern (e.g bug#2147483648).
The Item_func_mod objects never had maybe_null set, so users had no reason
to expect that they can be NULL, and may therefore deduce wrong results.
Now, set maybe_null.
sync using replicate-wild-ignore-table
Problem: changes in character set variables
before an action on an replication-ignored table
makes slave to forget new variable values.
Fix: initialize one_shot variables only when
4.1 -> 5.x replication is running.
Problem: Too confusing error message when cannot convert
between string and column character sets on INSERT and UPDATE.
Fix: producing a better error message, instead of "Data too long"
in such cases
Additional changes: Adding "DROP TABLE IF EXISTS" into several
tests to be safe against failures in previous tests.
When the client program had its stdout file descriptor closed by the calling
shell, after some amount of work (enough to fill a socket buffer) the server
would complain about a packet error and then disconnect the client.
This is a serious security problem. If stdout is closed before the mysql is
exec()d, then the first socket() call allocates file number 1 to communicate
with the server. Subsequent write()s to that file number (as when printing
results that come back from the database) go back to the server instead in
the command channel. So, one should be able to craft data which, upon being
selected back from the server to the client, and injected into the command
stream become valid MySQL protocol to do something nasty when sent /back/ to
the server.
The solution is to close explicitly the file descriptor that we *printf() to,
so that the libc layer and the OS layer both agree that the file is closed.
The executing code had a safety assertion so that it refused to free Items
that it didn't create. However, there is a case, undefined user variables,
which would put Items into the list to be freed.
Instead, do something that is more risky in expectation that the code will
be refactored soon, as Kostja wants to do: Remove the assertions from
prepare() and execute(). Put one assertion at a higher level, before
stmt->set_params_from_vars(), which may then create new to-be-freed Items .
(race cond)
It was possible for one thread to interrupt a Data Definition Language
statement and thereby get messages to the binlog out of order. Consider:
Connection 1: Drop Foo x
Connection 2: Create or replace Foo x
Connection 2: Log "Create or replace Foo x"
Connection 1: Log "Drop Foo x"
Local end would have Foo x, but the replicated slaves would not.
The fix for this is to wrap all DDL and logging of a kind in the same mutex.
Since we already use mutexes for the various parts of altering the server,
this only entails moving the logging events down close to the action, inside
the mutex protection.
The STACK_MIN_SIZE is currently set to 8192, when we actually need
(emperically discovered) 9236 bytes to raise an fatal error, on Ubuntu
Dapper Drake, libc6 2.3.6-0ubuntu2, Linux kernel 2.6.15-27-686, on x86.
I'm taking that as a new lower bound, plus 100B of wiggle-room for sundry
word sizes and stack behaviors.
The added test verifies in a cross-platform way that there are no gaps
between the space that we think we need and what we actually need to report
an error.
DOCUMENTERS: This also adds "let" to the mysqltest commands that evaluate
an argument to expand variables therein. (Only right of the "=", of course.)
The patch affects only test suite and has the following changes:
1. On starting Instance Manager -- added code for waiting for guarded
mysqld instances to create PID files;
2. Polishing;
3. Move IM-related operations out of mtr_process.pl into new dedicated
for IM file -- mtr_im.pl
- BUG#15934: Instance manager fails to work;
- BUG#18020: IM connect problem;
- BUG#18027: IM: Server_ID differs;
- BUG#18033: IM: Server_ID not reported;
- BUG#21331: Instance Manager: Connect problems in tests;
The only test suite has been changed
(server codebase has not been modified).
User name (host name) has limit on length. The server code relies on these
limits when storing the names. The problem was that sometimes these limits
were not checked properly, so that could lead to buffer overflow.
The fix is to check length of user/host name in parser and if string is too
long, throw an error.
