ZERO
When dates are represented internally as strings, i.e. when a string constant
is compared to a date value, both values are converted to long integers,
ostensibly for fast comparisons. DATE typed integer values are converted to
DATETIME by multiplying by 1,000,000 (each digit pair representing hour,
minute and second, respectively). But the mechanism did not distuinguish
cached INTEGER values, already in correct format, from newly converted
strings.
Fixed by marking the INTEGER cache as being of DATETIME format.
rpl_packet got a timeout failure sporadically on PB when stopping
slave. The real reason of this bug is that STOP SLAVE stopped
IO thread first and then stopped SQL thread. It was
possible that IO thread stopped after replicating part of a
transaction which SQL thread was executing. SQL thread would
be hung if the transaction could not be rolled back safely.
After this patch, STOP SLAVE will stop SQL thread first and then stop IO
thread, which guarantees that IO thread will fetch the reset of the
events of the transaction that SQL thread is executing, so that SQL
thread can finish the transaction if it cannot be rolled back safely.
Added below auxiliary files to make the test code neater.
restart_slave_sql.inc
rpl_connection_master.inc
rpl_connection_slave.inc
rpl_connection_slave1.inc
Undoing the patch, it complicates the code but is not the solution
I do not beleive newline mismatch could be the cause of this failure
First, I cannot see how this could be a problem, mtr ignores the newline
when reading the expect file, and the file is written and read on Windows.
Second, if this really was the problem it should have been deterministic:
either the newline is correctly interepreted or it is not.
Problem: the scanner function tested for strings "<![CDATA[" and
"-->" without checking input string boundaries, which led to valgrind's
"Conditional jump or move depends on uninitialised value(s)" error.
Fix: Adding boundary checking.
@ mysql-test/r/xml.result
@ mysql-test/t/xml.test
Adding test
@ strings/xml.c
Adding a helper function my_xml_parser_prefix_cmp(),
with input string boundary check.
Committing After latest merge.
Modified check_pct procedure to check return value of wait condition instead
of calling "dirty_pct".
Adding Review comments:
1) Added comment for success variable value
2) Procedure check_pct changed For Adding BOOLEAN input and SELECT QUERY Change
Introduced by the fix for bug#44766.
Problem: it's not correct to use args[0]->str_value as a buffer,
because args[0] may need this buffer for its own purposes.
Fix: adding a new class member tmp_value to use as return value.
@ mysql-test/r/ctype_many.result
@ mysql-test/t/ctype_many.test
Adding tests
@ sql/item_strfunc.cc
Changing code into traditional style:
use "str" as a buffer for the argument and tmp_value for the result value.
@ sql/item_strfunc.h
Adding tmp_value
Problem: when processing a query like:
SELECT '' LIKE '1' ESCAPE COUNT(1);
escape_item->val_str() was never executed and the "escape" class member
stayed initialized, which led to valgrind uninitialized memory error.
Note, a query with some tables in "FROM" clause
returns ER_WRONG_ARGUMENTS in the same situation:
SELECT '' LIKE '1' ESCAPE COUNT(1) FROM t1;
ERROR 1210 (HY000): Incorrect arguments to ESCAPE
Fix: disallowing using aggregate functions in ESCAPE clause,
even if there are no tables used. There is no much use of that anyway.
When mysqldadmin is run with sleep and count options,
it goes into an infinite loop and keeps executing the
specified command.
This happened because the statement, responsible for
decrementing the count value, was missing.
Fixed by adding a statement which will decrement the
count value for each iteration.
client/mysqladmin.cc:
Bug#58221 : mysqladmin --sleep=x --count=x keeps looping
Added a condition to check and decrement the count
value stored in nr_iterations per iteration.
mysql-test/r/mysqladmin.result:
Added a testcase for Bug#58221.
mysql-test/t/mysqladmin.test:
Added a testcase for Bug#58221.
Backport to 5.0.
/*![:version:] Query Code */, where [:version:] is a sequence of 5
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those
servers whose versions are larger than the version appearing in the
comment. It leads to a security issue when slave's version is larger
than master's. A malicious user can improve his privileges on slaves.
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.
This bug is fixed with the logic below:
- To replace '!' with ' ' in the magic comments which are not applied on
master. So they become common comments and will not be applied on slave.
- Example:
'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
will be binlogged as
'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/
IA64 and some other arcitectures use different float rounding mode and
i find no decent way to make it consistent.
So the test changed to be insensitive to this.
per-file messages:
mysql-test/t/gis.test
Bug#52208 gis fails on some platforms (Solaris, HP-UX, Linux)
--replace_result added
When mysqldump tries to dump information in xml format,
the result does not contain field level comments.
In order to retrieve various informations for a field/column,
mysqldump currently uses 'show fields from <tab>' statement.
The attributes returned by the statement lacks the information
regarding field comments.
Fixed by changing the query to one that probes I_S to retrieve
required field informations, including the field comment.
client/mysqldump.c:
Bug#13618 : mysqldump --xml omits comment on table field.
Replaced the 'show fields' command by a statement that
queries I_S, in order to retrieve information on all the
attributes that 'show fields' returns along-with an additional
column_comment information.
mysql-test/r/client_xml.result:
Result modifications for bug#13618.
mysql-test/r/mysqldump.result:
Result modifications for bug#13618.
mysql-test/t/mysqldump.test:
Added a testcase for bug#13618.
Backported the fix to 5.1.
Problem: the auxiliary test files rpl_start_server.inc and rpl_stop_server.inc
write a file that is later read by mtr. The bug was that the file was written
with platform-dependent newline terminators, i.e., \r\n on windows, whereas mtr
only understands \n.
Fix: write the file so that it uses \n on all platforms.
mysql-test/include/rpl_start_server.inc:
Force test to use \n instead of platform-dependent newline terminator.
mysql-test/include/rpl_stop_server.inc:
Force test to use \n instead of platform-dependent newline terminator.
null from mysql_store_result.
mysqlslap segfaults at a point when it tries to fetch rows from
the result set.
Under some circumstances, mysql_store_result can return 'NULL',
even after query execution (mysql_query) succeeds, and eventually
a segfault might occur if same unchecked return value is passed
to mysql_fetch_row.
Fixed by adding a check on mysql_store_result's return value.
client/mysqlslap.c:
Bug#59109 : mysqlslap crashes on mysql_fetch_row after ignoring
null from mysql_store_result.
Added a check on mysql_store_result's return value. A 'NULL' return
value here shows an erroneous situation as mysql_field_count has already
reported a non-zero value.
other crashes
Some string manipulating SQL functions use a shared string object intended to
contain an immutable empty string. This object was used by the SQL function
SUBSTRING_INDEX() to return an empty string when one argument was of the wrong
datatype. If the string object was then modified by the sql function INSERT(),
undefined behavior ensued.
Fixed by instead modifying the string object representing the function's
result value whenever string manipulating SQL functions return an empty
string.
Relevant code has also been documented.
The test case fails with out of memory while updating a table
with several multi-megabytes sized rows. This can probably be too
exhausting for PB2 env.
The quick fix here is to reduce the size of the biggest
row (256MB) so that it becomes a little smaller (64MB).
INVOKER-security view access check wrong".
When privilege checks were done for tables used from an
INVOKER-security view which in its turn was used from
a DEFINER-security view connection's active security
context was incorrectly used instead of security context
with privileges of the second view's creator.
This meant that users which had enough rights to access
the DEFINER-security view and as result were supposed to
be able successfully access it were unable to do so in
cases when they didn't have privileges on underlying tables
of the INVOKER-security view.
This problem was caused by the fact that for INVOKER-security
views TABLE_LIST::security_ctx member for underlying tables
were set to 0 even in cases when particular view was used from
another DEFINER-security view. This meant that when checks of
privileges on these underlying tables was done in
setup_tables_and_check_access() active connection security
context was used instead of context corresponding to the
creator of caller view.
This fix addresses the problem by ensuring that underlying
tables of an INVOKER-security view inherit security context
from the view and thus correct security context is used for
privilege checks on underlying tables in cases when such view
is used from another view with DEFINER-security.
mysql-test/r/view_grant.result:
Added coverage for various combinations of DEFINER and
INVOKER-security views, including test for bug #58499
"DEFINER-security view selecting from INVOKER-security
view access check wrong".
mysql-test/t/view_grant.test:
Added coverage for various combinations of DEFINER and
INVOKER-security views, including test for bug #58499
"DEFINER-security view selecting from INVOKER-security
view access check wrong".
sql/sql_view.cc:
When opening a non-suid view ensure that its underlying
tables will get the same security context as use for
checking privileges on the view, i.e. security context
of view invoker. This context can be different from the
security context which is currently active for connection
in cases when this non-suid view is used from a view with
suid security. Inheriting security context in such situation
allows correctly apply privileges of creator of suid view
in checks for tables of non-suid view (since in this
situation creator/definer of suid view serves as invoker
for non-suid view).
Item_func_spatial_collection::fix_length_and_dec didn't call parent's method, so
the maybe_null was set to '0' after it. But in this case the result was
just NULL, that caused wrong behaviour.
per-file comments:
mysql-test/r/gis.result
Bug #57321 crashes and valgrind errors from spatial types
test result updated.
mysql-test/t/gis.test
Bug #57321 crashes and valgrind errors from spatial types
test case added.
sql/item_geofunc.h
Bug #57321 crashes and valgrind errors from spatial types
Item_func_geometry::fix_length_and_dec() called in
Item_func_spatial_collection::fix_length_and_dec().
tmptable needed
The function DEFAULT() works by modifying the the data buffer pointers (often
referred to as 'record' or 'table record') of its argument. This modification
is done during name resolution (fix_fields().) Unfortunately, the same
modification is done when creating a temporary table, because default values
need to propagate to the new table.
Fixed by skipping the pointer modification for fields that are arguments to
the DEFAULT function.
if max_allowed_packet >= 16M.
This bug was introduced by patch for bug#42503.
This patch restores behaviour that there was before patch
for bug#42503 was applied.
sql/net_serv.cc:
Restored original right condition.
The problem from a user point of view was that on Solaris the
time related functions (e.g. NOW(), SYSDATE(), etc) would always
return a fixed time.
This bug was happening due to a logic in the time retrieving
wrapper function which would only call the time() function every
half second. This interval between calls would be calculated
using the gethrtime() and the logic relied on the fact that time
returned by it is monotonic.
Unfortunately, due to bugs in the gethrtime() implementation,
there are some cases where the time returned by it can drift
(See Solaris bug id 6600939), potentially causing the interval
calculation logic to fail.
The solution is to retrieve the correct time whenever a drift in
the time returned by gethrtime() is detected. That is, do not
use the cached time whenever the values (previous and current)
returned by gethrtime() are not monotonically increasing.
mysys/my_getsystime.c:
Do not used the cached time if gethrtime is not monotonic.
to crash mysqld".
handler::pushed_cond was not always properly reset when table objects where
recycled via the table cache.
handler::pushed_cond is now set to NULL in handler::ha_reset(). This should
prevent pushed conditions from (incorrectly) re-apperaring in later queries.
From a user perspective, the problem is that a FLUSH LOGS or SIGHUP
signal could end up associating the stdout and stderr to random
files. In the case of this bug report, the streams would end up
associated to InnoDB ibd files.
The freopen(3) function is not thread-safe on FreeBSD. What this
means is that if another thread calls open(2) during freopen()
is executing that another thread's fd returned by open(2) may get
re-associated with the file being passed to freopen(3). See FreeBSD
PR number 79887 for reference:
http://www.freebsd.org/cgi/query-pr.cgi?pr=79887
This problem is worked around by substituting a internal hook within
the FILE structure. This avoids the loss of atomicity by not having
the original fd closed before its duplicated.
Patch based on the original work by Vasil Dimov.
include/my_sys.h:
Export my_freopen.
mysys/my_fopen.c:
Add a my_freopen abstraction to workaround bugs in specific OSes.
Add a prototype for getosreldate() as older FreeBSD versions did
not define one.
sql/log.cc:
Move freopen abstraction code over to mysys.
The streams are now only reopened for writing.
Do not use nested AC_CHECK_FUNC() because they result in:
./configure: line 52688: syntax error: unexpected end of file
(which happens only on some platforms and does not happen on others,
I have no idea what is the reason for this)
AC_CHECK_FUNCS(f1 f2 f3, ACTION_IF_PRESENT)
ACTION_IF_PRESENT is executed if any of f1, f2 or f3 is present.
Fix this misusage, we want the action to be executed if all of the
functions are present.
