Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds
during the leap second.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time
representations) with leap seconds (ending on :59:60 or 59:61) will still be
considered illegal and discarded by the server with an error or
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.
mysql-test/r/timezone3.result:
Bug #39920: test case
mysql-test/std_data/Moscow_leap:
Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i
to accomodate for the 2008 leap second
mysql-test/t/timezone3.test:
Bug #39920: test case
sql/tztime.cc:
Bug #39920: adjust leap seconds (:60 or :61) to :59
sql/tztime.h:
Bug #39920: adjust leap seconds (:60 or :61) to :59
TABLE_LIST doesn't free Strings in its string lists
(TABLE_LIST::use_index and TABLE_liST::ignore_index), so
calling c_ptr_safe() on that Strings leads to memleaks.
OTOH "safe" c_ptr_safe() is not necessary there and we can
replace it with c_ptr().
an error
Even after the fix for bug 28701 visible behaviors of
SELECT FROM a view and SELECT FROM a regular table are
little bit different:
1. "SELECT FROM regular table USE/FORCE/IGNORE(non
existent index)" fails with a "ERROR 1176 (HY000):
Key '...' doesn't exist in table '...'"
2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
with a "ERROR 1221 (HY000): Incorrect usage of
USE/IGNORE INDEX and VIEW". OTOH "SHOW INDEX FROM
view" always returns empty result set, so from the point
of same behaviour view we trying to use/ignore non
existent index.
To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.
mysql-test/r/view.result:
Added test case for bug #33461.
Updated test case for bug 28701.
mysql-test/t/view.test:
Added test case for bug #33461.
Updated test case for bug 28701.
sql/sql_view.cc:
Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws
an error
To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.
The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES
were assuming that all the system variables are in system charset (UTF-8).
However the variables that are settable through command line will have a different
character set (character_set_filesystem).
Fixed the server to remember the correct character set of basedir, datadir, tmpdir,
ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave
variables and use it when processing data.
mysql-test/r/ctype_filesystem.result:
Bug #37339: test case (should be in utf-8)
mysql-test/t/ctype_filesystem-master.opt:
Bug #37339: test case (should be in ISO-8859-1)
mysql-test/t/ctype_filesystem.test:
Bug #37339: test case
sql/mysqld.cc:
Bug #37339: remember the correct character set for init_slave and init_connect
sql/set_var.cc:
Bug #37339:
- remember the character set of the relevant variables
- implement storing and using the correct
character set
sql/set_var.h:
Bug #37339: implement storing and using the correct
character set
sql/sql_show.cc:
Bug #37339: implement storing and using the correct
character set
The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win,
If MySQL is compiled with valgrind there are errors about
using of uninitialized variable(orig_table).
The fix is to set field->orig_table correct value.
mysql-test/r/innodb_mysql.result:
test result
mysql-test/t/innodb_mysql.test:
test case
sql/sql_base.cc:
set field->orig_table to 'table' value because it may be bogus and
it leads to crash on Field_string::type() function.
enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())
mysql-test/r/subselect.result:
test result
mysql-test/t/subselect.test:
test case
sql/mysql_priv.h:
added UNCACHEABLE_CHECKOPTION flag
sql/sql_update.cc:
enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())
set DATE|DATETIME value to 0 if ALLOW_INVALID_DATES sql_mode is not enabled.
sql/field.cc:
set DATE|DATETIME value to 0 if ALLOW_INVALID_DATES sql_mode is not enabled.
tests/mysql_client_test.c:
test case
We pretended that TIMEDIFF() would always return positive results;
this gave strange results in comparisons of the TIMEDIFF(low,hi)<TIME(0)
type that rendered a negative result, but still gave false in comparison.
We also inadvertantly dropped the sign when converting times to
decimal.
CAST(time AS DECIMAL) handles signs of the times correctly.
TIMEDIFF() marked up as signed. Time/date comparison code switched to
signed for clarity.
mysql-test/r/func_sapdb.result:
show that time-related comparisons work with negative
time values now.
show that converting time to DECIMAL no longer drops sign.
mysql-test/t/func_sapdb.test:
show that time-related comparisons work with negative
time values now.
show that converting time to DECIMAL no longer drops sign.
sql/item_cmpfunc.cc:
signed returns
sql/item_cmpfunc.h:
signed now (time/date < > =)
sql/item_func.cc:
signed now
sql/item_timefunc.h:
Functions such as TIMEDIFF() return signed results!
The file-comments pretended we were doing that all along, anyway...
sql/my_decimal.cc:
heed sign when converting time to my_decimal;
times may actually be negative!
Needed for SELECT CAST(time('-73:42:12') AS DECIMAL);
sql/mysql_priv.h:
using signed for dates and times now
Problem: in 5.0 'check table for upgrade' doesn't detect
incompatible collation changes made in 5.0.48.
Fix: backport #39585 fix to 5.0
sql/handler.cc:
Fix for bug#40984: backport fix from 39585 into 5.0
- backport of #39585 fix
sql/handler.h:
Fix for bug#40984: backport fix from 39585 into 5.0
- backport of #39585 fix
ONLY_FULL_GROUP_BY
The check for non-aggregated columns in queries with aggregate function, but without
GROUP BY was treating all the parts of the query as if they are in the SELECT list.
Fixed by ignoring the non-aggregated fields in the WHERE clause.
mysql-test/r/func_group.result:
Bug #39656: test case
mysql-test/t/func_group.test:
Bug #39656: test case
sql/sql_select.cc:
Bug #39656: ignore the new non-aggregated column refs in a WHERE
by saving the state so far and then adding only the new values of the other
parts of the bitmask.
the problem is the same as reported in bug#20835,
so the fix is backport of bug#20835 patch.
mysql-test/r/subselect.result:
test result
mysql-test/t/subselect.test:
test case
returns truncated results
Problem: performig conversion from {INT, DECIMAL, REAL} to CHAR
we incorrectly set its max length in some cases that may lead
to truncated results returned.
Fix: properly set CONVERT({INT, DECIMAL, REAL}, CHAR) result's
max length.
mysql-test/r/ctype_utf8.result:
Fix for bug#36772: When using UTF8, CONVERT with GROUP BY
returns truncated results
- test result.
mysql-test/t/ctype_utf8.test:
Fix for bug#36772: When using UTF8, CONVERT with GROUP BY
returns truncated results
- test case.
sql/item_timefunc.cc:
Fix for bug#36772: When using UTF8, CONVERT with GROUP BY
returns truncated results
- calculating Item_char_typecast::max_length use initial
argument's charset mbmaxlen instead of from_cs->mbmaxlen,
as from_cs may differ in some case (see comment above).
It was possible to crash a mysqld build with EXTRA_DEBUG using
CREATE TABLE ... COMMENT with a specially-crafted UTF-8 string.
This CS removes the check that caused it since it no longer
applies in current servers anyway, and adds comments instead
to avoid future confusion.
mysql-test/r/strict.result:
Try to crash mysqld with a "suitable" multi-byte (3-byte UTF-8) string
for a table comment.
mysql-test/t/strict.test:
Try to crash mysqld with a "suitable" multi-byte (3-byte UTF-8) string
for a table comment.
sql/unireg.cc:
Talk at length about limits in .frm form-info, characters vs bytes,
inlined vs extra-segement TABLE-COMMENTS, and the differences in
6.0+ vs <6.0 when it comes to UTF-8.
Also, remove a check that no longer applies and that could lead to
problems in pathological cases.
Problem: memory leak occurs when we open a federated table
that has its share in the hash.
Fix: free not used memory.
Note: the fix should NOT be merged to 5.1 (the code changed).
sql/ha_federated.cc:
Fix for bug#40875: Memory leak in FEDERATED handler
- free memory (tmp_share.scheme) allocated in the parse_url()
if it isn't used anymore.
When a CSV file contained comma separated elements
that were not enclosed in quotes, it was causing the
mysql server to crash.
The old algorithm that parsed the content of a row in
mysql 5.0 was assuming that the values of the fields
in a .CSV file will be enclosed in quotes and will be
separated by commas.
This was causing the old algorithm to fail when the
content of the file resembled the following
3,"sans quotes"
The CSV engine that is part of mysql 5.0 was expecting
the above to be
"3","sans quotes"
The above is just one example of where the engine was
failing for what would be recognized as a valid .CSV
file content otherwise.
The proposed fix changes the old algorithm being used
to parse rows from the .CSV file to handle two separate
cases
1) When the current field of the row is enclosed in quotes
2) When the current field of the row is not enclosed in
quotes
mysql-test/r/csv.result:
Contains additional test output corresponding to the new
tests added.
mysql-test/t/csv.test:
Contains additional tests for testing the behaviour of the CSV
storage engine when the fields are not enclosed in quotes.
sql/examples/ha_tina.cc:
Changes the parsing logic of the rows in a CSV file to account for
fields that are not enclosed in quotes.
Item_func_div didn't calculate the precision of the result properly.
The result of 5/0.0001 is 5000 so we have to add decimals of the divisor
to the planned precision.
per-file comments:
mysql-test/r/type_newdecimal.result
Bug#31616 div_precision_increment description looks wrong
test result fixed
mysql-test/t/type_newdecimal.test
Bug#31616 div_precision_increment description looks wrong
test case
sql/item_func.cc
Bug#31616 div_precision_increment description looks wrong
precision must be increased with args[1]->decimals parameter
missing after downgrade
Obsolete arc/ directory and view .frm file backup support
has been removed by the patch for bug 17823. However, that
bugfix caused a problem with "live downgrades" of the
server: if we rename some view 4 times under 5.1.29/5.0.72
and then try to rename it under 5.1.28/5.0.70 on the same
database, the server fails with a error:
query 'RENAME TABLE ... TO ...' failed: 6: Error on
delete of '....frm-0001' (Errcode: 2)
Also .frm file of that view may be lost (renamed to .frm~).
The server failed because it tried to rename latest 3
backup .frm files renaming the view: the server used an
integer value of the "revision" field of .frm file to
extract those file names. After the fix for bug 17823 those
files were not created/maintained any more, however the
"revision" field was incremented as usual. So, the server
failed renaming non existent files.
This fix solves the problem by removing the support for
"revision" .frm file field:
1. New server silently ignores existent "revision" fields
in old .frm files and never write it down;
2. Old server assumes, that missing "revision" field in new
.frm files means default value of 0.
3. Accordingly to the fix for bug 17823 the new server
drops arc/ directory on alter/rename view, so after
"live downgrade" old server begins maintenance of the
arc/ directory from scratch without conflicts with .frm
files.
sql/parse_file.cc:
Bug #40021: Renaming view fails, archived .frm for view is
missing after downgrade
1. static write_parameter(): the old_version parameter
and the section for FILE_OPTIONS_REV have been re moved.
2. write_parameter(): the max_versions parameter has been
removed;
3. sql_create_definition_file(): removal of dead code;
4. rename_in_schema_file(): revision and num_view_backups
parameters and dead code have been removed;
5. File_parser::parse(): FILE_OPTIONS_REV section has been
removed.
sql/parse_file.h:
Bug #40021: Renaming view fails, archived .frm for view is
missing after downgrade
1. The FILE_OPTIONS_REV constant has been removed.
2. sql_create_definition_file and rename_in_schema_file
functions: obsolete versions, revision and
num_view_backups parameters have been removed.
sql/sql_db.cc:
Bug #40021: Renaming view fails, archived .frm for view is
missing after downgrade
Commentary update.
sql/sql_trigger.cc:
Bug #40021: Renaming view fails, archived .frm for view is
missing after downgrade
sql_create_definition_file() calls have been updates to
new parameter lists.
sql/sql_view.cc:
Bug #40021: Renaming view fails, archived .frm for view is
missing after downgrade
1. The mysql_create_view function code is used for both
CREATE VIEW and ALTER queries, but query cache is
necessary for ALTER command only. Check for a non first
view revision has been replaced with a direct check for
ALTER query.
2. The num_view_backups global constant has been removed.
3. view_parameters: the "revision" .frm field support has
been removed.
4. sql_create_definition_file and rename_in_schema_file
function calls have been updates to new parameter lists.
sql/table.h:
Bug #40021: Renaming view fails, archived .frm for view is
missing after downgrade
TABLE_LIST: the revision field has been removed.
status
The problem appears to be a race condition, when service is being
stopped right after startup. We set the service status to SERVICE_RUNNING
way too early it cannot yet handle stop requests - initialization has
not finished and hEventShutdown that signals server to stop is not yet
created. If somebody issues "net stop MySQL" at this time, MySQL is not
informed about the stop and continues to run as usual, while
NTService::ServiceMain() stucks forever waiting for mysql's "main" thread
to finish.
Solution is to remain in SERVICE_START_PENDING status until after server
initialization is fully complete and only then change the status to
SERVICE_RUNNING. In SERVICE_START_PENDING we do not accept service control
requests, i.e it is not possible to stop service in that time.
sql/mysqld.cc:
Set service status to running after all initialization is complete
sql/nt_servc.cc:
New method SetRunning() to be called by application
to set service status to SERVICE_RUNNING when apllication
has finished initialization.
sql/nt_servc.h:
New method SetRunning() to be called by application
when initialization completes
issue 'The storage engine for the table doesn't support check' note for I_S tables
mysql-test/r/mysqlcheck.result:
test result
mysql-test/t/mysqlcheck.test:
test case
sql/sql_table.cc:
issue 'The storage engine for the table doesn't support check' note for I_S tables
I think we don't need to issue an error statement in the convert_search_mode_to_innobase().
Returning the PAGE_CUR_UNSUPP value is enough as allows to handle this
case depending on the requirements.
per-file comments:
sql/ha_innodb.cc
Bug#31435 ha_innodb.cc:3983: ulint convert_search_mode_to_innobase(ha_rkey_function): Asse
no error issued in convert_search_mode_to_innobase.
ha_innobase::records_in_range() returns HA_POS_ERROR if search mode isn't supported.
With fix for bug 25951 index hints are ignored for fulltext
searches, as handling of fulltext indexes is different from
handling regular indexes. Meaning it is not possible to
implement true index hints support for fulltext indexes within
the scope of current fulltext architecture.
The problem is that prior to fix for bug 25951, some useful
index hints still could be given for boolean mode searches.
This patch implements special index hints support for fulltext
indexes with the following characteristics:
- all index hints are still ignored for NLQ mode searches -
it cannot work without an index;
- for 5.1 and up index hints FOR ORDER BY and FOR GROUP BY are
still ignored for fulltext indexes;
- boolean mode searches honor USE/FORCE/IGNORE INDEX hints;
- as opposed to index hints for regular indexes, index hints
for fulltext BOOLEAN mode searches affect the usage of the
index for the whole query.
mysql-test/r/fulltext.result:
A test case for BUG#38842.
mysql-test/t/fulltext.test:
A test case for BUG#38842.
sql/item_func.cc:
For boolean mode searches, which can work without fulltext
index, use keys_in_use_for_query bitmap instead of keys_in_use.
The effect is that boolean mode searches now honor index hints.
A string buffers which were included in the 'view' data structure
were allocated on the stack, causing an invalid pointer when used
after the function returned.
The fix: use copy of values for view->md5 & view->queries
mysql-test/r/view.result:
test result
mysql-test/t/view.test:
test case
sql/sql_view.cc:
A string buffers which were included in the 'view' data structure
were allocated on the stack, causing an invalid pointer when used
after the function returned.
The fix: use copy of values for view->md5 & view->queries
- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out
that HAVING is always FALSE
re-committing to put the fix into 5.0 and 5.1
mysql-test/r/group_by.result:
BUG#38072: Wrong result: HAVING not observed in a query with aggregate
- Testcase
mysql-test/t/group_by.test:
BUG#38072: Wrong result: HAVING not observed in a query with aggregate
- Testcase
sql/sql_select.h:
BUG#38072: Wrong result: HAVING not observed in a query with aggregate
- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out
that HAVING is always FALSE
Visual Studio 2008 Express edition does not include message compiler mc.exe
It is not possible to build MySQL server if only VC2008 Express is installed,
because we use mc.exe to generate event log messages.
This patch removes the mc.exe dependency. Generated files message.h,
message.rc and MSG00001.bin are checked into source code repository.
Instructions on how to add or change messages are added to messages.mc
The problem was that the server did not robustly handle a
unilateral roll back issued by the Resource Manager (RM)
due to a resource deadlock within the transaction branch.
By not acknowledging the roll back, the server (TM) would
eventually corrupt the XA transaction state and crash.
The solution is to mark the transaction as rollback-only
if the RM indicates that it rolled back its branch of the
transaction.
mysql-test/r/xa.result:
Add test case result for Bug#28323
mysql-test/t/xa.test:
Add test case for Bug#28323
sql/handler.cc:
Reset XID only at the end of the global transaction.
sql/share/errmsg.txt:
Add new error codes.
sql/sql_class.h:
Remember the error reported by the Resource Manager.
sql/sql_parse.cc:
Rollback the transaction if the Resource Manager reported
a error and rolled back its branch of the transaction.
fails after the first time
Two separate problems :
1. When flattening joins the linked list used for name resolution
(next_name_resolution_table) was not updated.
Fixed by updating the pointers when extending the table list
2. The items created by expanding a * (star) as a column reference
were marked as fixed, but no cached table was assigned to them
(unlike what Item_field::fix_fields does).
Fixed by assigning a cached table (so the re-preparation is done
faster).
Note that the fix for #2 hides the fix for #1 in most cases
(except when a table reference cannot be cached).
mysql-test/r/sp.result:
Bug #33811: test case
mysql-test/t/sp.test:
Bug #33811: test case
sql/sql_base.cc:
Bug #33811: cache the table for Item_fields created by expanding '*'
sql/sql_select.cc:
Bug #33811: maintain a correct name resolution chain when
flattening joins.
IS NULL was not checking the correct row in a HAVING context.
At the first row of a new group (where the HAVING clause is evaluated)
the column and SELECT list references in the HAVING clause should
refer to the last row of the previous group and not to the current one.
This was not done for IS NULL, because it was using Item::is_null() doesn't
have a Item_is_null_result() counterpart to access the data from the
last row of the previous group. Note that all the Item::val_xxx() functions
(e.g. Item::val_int()) have their _result counterparts (e.g. Item::val_int_result()).
Fixed by implementing a is_null_result() (similarly to int_result()) and
calling this instead of is_null() column and SELECT list references inside
the HAVING clause.
mysql-test/r/having.result:
Bug #38637: test case
mysql-test/t/having.test:
Bug #38637: test case
sql/item.cc:
Bug #38637: implement Item::is_null_result() and call it
from Item_ref and Item_field as appropriate.
sql/item.h:
Bug #38637: implement Item::is_null_result() and call it
from Item_ref and Item_field as appropriate.
sql/item_func.cc:
Bug #38637: implement Item::is_null_result() and call it
from Item_ref and Item_field as appropriate.
sql/item_func.h:
Bug #38637: implement Item::is_null_result() and call it
from Item_ref and Item_field as appropriate.
Server crashed during a sort order optimization
of a dependent subquery:
SELECT
(SELECT t1.a FROM t1, t2
WHERE t1.a = t2.b AND t2.a = t3.c
ORDER BY t1.a)
FROM t3;
Bitmap of tables, that the reference to outer table
column uses, in addition to the regular table bit
has the OUTER_REF_TABLE_BIT bit set.
The only_eq_ref_tables function traverses this map
bit by bit simultaneously with join->map2table list.
Obviously join->map2table never contains an entry
for the OUTER_REF_TABLE_BIT pseudo-table, so the
server crashed there.
The only_eq_ref_tables function has been modified
to traverse regular table bits only like the
update_depend_map function (resetting of the
OUTER_REF_TABLE_BIT there is enough, but
resetting of the whole set of PSEUDO_TABLE_BITS
is used there for sure).
mysql-test/r/order_by.result:
Added test case for bug #39844.
mysql-test/t/order_by.test:
Added test case for bug #39844.
sql/sql_select.cc:
Bug #39844: Query Crash Mysql Server 5.0.67
The only_eq_ref_tables function has been modified
to traverse regular table bits only like the
update_depend_map function (resetting of the
OUTER_REF_TABLE_BIT there is enough, but
resetting of the whole set of PSEUDO_TABLE_BITS
is used there for sure).
The problem is that the offset argument of the limit clause
might be truncated on a 32-bits server built without big
tables support. The truncation was happening because the
original 64-bits long argument was being cast to a 32-bits
(ha_rows) offset counter.
The solution is to check if the conversing resulted in value
truncation and if so, the offset is set to the maximum possible
value that can fit on the type.
mysql-test/r/limit.result:
Add test case result for Bug#37075
mysql-test/t/limit.test:
Add test case for Bug#37075
sql/sql_lex.cc:
Check for truncation of the offset value. If value was
truncated, set to the maximum possible value.
If delayed insert fails to upgrade the lock it was not
freeing the temporary memory storage used to keep
newly constructed blob values in memory.
Fixed by iterating over the remaining rows in the delayed
insert rowset and freeing the blob storage for each row.
No test suite because it involves concurrent delayed inserts
on a table and cannot easily be made deterministic.
Added a correct valgrind suppression for Fedora 9.
mysql-test/valgrind.supp:
Added a vagrind suppression for Fedora 9
sql/sql_insert.cc:
Bug #38693: free the blobs temp storage on error.
