timestamp primary key
Since TIMESTAMP values are adjusted by the current time zone
settings in both numeric and string contexts, using any
expressions involving TIMESTAMP values as a
(sub)partitioning function leads to undeterministic behavior of
partitioned tables. The effect may vary depending on a storage
engine, it can be either incorrect data being retrieved or
stored, or an assertion failure. The root cause of this is the
fact that the calculated partition ID may differ from a
previously calculated ID for the same data due to timezone
adjustments of the partitioning expression value.
Fixed by disabling any expressions involving TIMESTAMP values
to be used in partitioning functions with the follwing two
exceptions:
1. Creating or altering into a partitioned table that violates
the above rule is not allowed, but opening existing such tables
results in a warning rather than an error so that such tables
could be fixed.
2. UNIX_TIMESTAMP() is the only way to get a
timezone-independent value from a TIMESTAMP column, because it
returns the internal representation (a time_t value) of a
TIMESTAMP argument verbatim. So UNIX_TIMESTAMP(timestamp_column)
is allowed and should be used to fix existing tables if one
wants to use TIMESTAMP columns with partitioning.
SPATIAL and FULLTEXT indexes don't support algorithm
selection.
Disabled by creating a special grammar rule for these
in the parser.
Added some encasulation of duplicate parser code.
A few problems were found in the fix for bug 43668:
1) Comparison of the YEAR column with NULL always returned TRUE;
2) Comparison of the YEAR column with constants always returned
unpredictable result;
3) Unnecessary conversion warnings when comparing a non-integer
constant with a NULL value in the YEAR column;
The problems described above have been resolved with an
exception: zero (i.e. invalid) YEAR column value comparison
with 00 or 2000 still fail (it is not a regression and it was
not a regression), so MIN/MAX on YEAR column containing zero
value still fail.
Arg_comparator uses Item_cache objects to store constants being compared when
they're need a type conversion. Because this cache wasn't initialized properly
Arg_comparator might produce wrong comparison result.
The Arg_comparator::cache_converted_constant function now initializes cache
prior to usage.
There are three issues that caused rpl_killed_ddl fails sporadically
in pb2:
1) thd->clear_error() was not called before create Query event
if operation is executed successfully.
2) DATABASE d2 might do exist because the statement to CREATE or
ALTER it was killed
3) because of bug 43353, kill the query that do DROP FUNCTION or
DROP PROCEDURE can result in SP not found
This patch fixed all above issues by:
1) Called thd->clear_error() if the operation succeeded.
2) Add IF EXISTS to the DROP DATABASE d2 statement
3) Temporarily disabled testing DROP FUNCTION/PROCEDURE IF EXISTS.
Part 2 :
There was a special optimization on the ref access method for
ORDER BY ... DESC that was set without actually looking on the type of the
selected index for ORDER BY.
Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared
to the ASC that has been fixed with the previous fix).
escaped field names
When in mixed or statement mode, the master logs LOAD DATA
queries by resorting to an Execute_load_query_log_event. This
event does not contain the original query, but a rewritten
version of it, which includes the table field names. However, the
rewrite does not escape the field names. If these names match a
reserved keyword, then the slave will stop with a syntax error
when executing the event.
We fix this by escaping the fields names as it happens already
for the table name.
field='const1' AND field='const2' in some cases
Building multiple equality predicates containing
a constant which is compared as a datetime (with a field)
we should take this fact into account and compare the
constant with another possible constatns as datetimes
as well.
E.g. for the
SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00'
we should compare '2001-01-01' with '2001-01-01 00:00:00' as
datetimes but not as strings.
The problem was that the multiple evaluations of a ENCODE or
DECODE function within a single statement caused the random
generator to be reinitialized at each evaluation, even though
the parameters were constants.
The solution is to initialize the random generator only once
if the password (seed) parameter is constant.
This patch borrows code and ideas from Georgi Kodinov's patch.
"mysql_upgrade (ver 5.1) add 3 fields to mysql.proc table but does
not set values".
mysql_upgrade (ver 5.1) adds 3 fields (character_set_client,
collation_connection and db_collation) to the mysql.proc table, but
does not set any values. When we run stored procedures, which were
created with mysql 5.0, a warning is logged into the error log.
The solution to this is for mysql_upgrade to set default best guess
values for these fields. A warning is also written during upgrade, to
make the user aware that default values are set.
When checking for an error after removing the special view error handler the code
was not taking into account that open_tables() may fail because of the current
statement being killed.
Added a check for thd->killed.
Added a client program to test it.
Problem: Item_char_typecast reported wrong max_length when
casting to BINARY, which lead, in particular, in wrong
"ORDER BY BINARY(char_column)" results.
Fix: making Item_char_typecast report correct max_length.
@ mysql-test/r/ctype_utf16.result
Fixing old incorrect test result.
@ mysql-test/r/ctype_utf32.result
Fixing old incorrect test result.
@ mysql-test/r/ctype_utf8.result
Adding new test
@ mysql-test/t/ctype_utf8.test
Adding new test
@ sql/item_timefunc.cc
Making Item_char_typecast report correct max_length
when cast is done to BINARY.
Problem: SHOW CREATE FUNCTION and SELECT DTD_IDENTIFIER FROM I_S.ROUTINES
returned wrong values in case of ENUM return data type and UCS2
character set.
Fix: the string to collect returned data type was incorrectly set to
"binary" character set, therefore UCS2 values where returned with
extra '\0' characters.
Setting string character set to creation_ctx->get_client_cs()
in sp_find_routine(), and to system_charset_info in sp_create_routine
fixes the problem.
Adding tests:
- the original test with Latin letters
- an extra test with non-Latin letters
Actually there is two different bugs.
The first one caused crash on queries with WHERE condition over views
containing WHERE condition. A wrong check for prepared statement phase led
to items for view fields being allocated in the execution memory and freed
at the end of execution. Thus the optimized WHERE condition refers to
unallocated memory on the second execution and server crashed.
The second one caused by the Item_cond::compile function not saving changes
it made to the item tree. Thus on the next execution changes weren't
reverted and server crashed on dereferencing of unallocated space.
The new helper function called is_stmt_prepare_or_first_stmt_execute
is added to the Query_arena class.
The find_field_in_view function now uses
is_stmt_prepare_or_first_stmt_execute() to check whether
newly created view items should be freed at the end of the query execution.
The Item_cond::compile function now saves changes it makes to item tree.
SET TRANSACTION ISOLATION LEVEL is used to temporarily set
the trans.iso.level for the next transaction. After the
transaction, the iso.level is (re-)set to value of the
session variable 'tx_isolation'.
The bug is caused by setting the thd->variables.tx_isolation
field to the value of the session variable upon each
statement commit. It should only be set at the end of the
full transaction.
The fix has been to remove the setting of the variable in
ha_autocommit_or_rollback if we're in a transaction, as it
will be correctly set in either ha_rollback or
ha_commit_one_phase.
If, on the other hand, we're in autocommit mode, tx_isolation
will be explicitly set here.
1. BUG#47720 - REPLACE INTO Autoincrement column with negative values.
Detailed revision comments:
r6235 | sunny | 2009-11-26 01:14:42 +0200 (Thu, 26 Nov 2009) | 9 lines
branches/5.1: Fix Bug#47720 - REPLACE INTO Autoincrement column with negative values.
This bug is similiar to the negative autoinc filter patch from earlier,
with the additional handling of filtering out the negative column values
set explicitly by the user.
rb://184
Approved by Heikki.
1. BUG#49032 - auto_increment field does not initialize to last value
in InnoDB Storage Engine
2. Fix whitespace issues and fix tests and make read float/double arg const
Detailed revision comments:
r6231 | sunny | 2009-11-25 10:26:27 +0200 (Wed, 25 Nov 2009) | 7 lines
branches/5.1: Fix BUG#49032 - auto_increment field does not initialize to last value in InnoDB Storage Engine.
We use the appropriate function to read the column value for non-integer
autoinc column types, namely float and double.
rb://208. Approved by Marko.
r6232 | sunny | 2009-11-25 10:27:39 +0200 (Wed, 25 Nov 2009) | 2 lines
branches/5.1: This is an interim fix, fix white space errors.
r6233 | sunny | 2009-11-25 10:28:35 +0200 (Wed, 25 Nov 2009) | 2 lines
branches/5.1: This is an interim fix, fix tests and make read float/double arg const.
r6234 | sunny | 2009-11-25 10:29:03 +0200 (Wed, 25 Nov 2009) | 2 lines
branches/5.1: This is an interim fix, fix whitepsace issues.
1. BUG#48482 - innodb-autoinc.test fails with results difference
2. enable the disabled test
Detailed revision comments:
r6230 | sunny | 2009-11-24 23:52:43 +0200 (Tue, 24 Nov 2009) | 3 lines
branches/5.1: Fix autoinc failing test results.
(this should be skipped when merging 5.1 into zip)
for each record'
There was an error in an internal structure in the range
optimizer (SEL_ARG). Bad design causes parts of a data
structure not to be initialized when it is in a certain
state. All client code must check that this state is not
present before trying to access the structure's data. Fixed
by
- Checking the state before trying to access data (in
several places, most of which not covered by test case.)
- Copying the keypart id when cloning SEL_ARGs
BUG#46000 - using index called GEN_CLUST_INDEX crashes server
Detailed revision comments:
r6180 | jyang | 2009-11-17 10:54:57 +0200 (Tue, 17 Nov 2009) | 7 lines
branches/5.0: Merge/Port fix for bug #46000 from branches/5.1
-r5895 to branches/5.0. Disallow creating index with the
name of "GEN_CLUST_INDEX" which is reserved for the default
system primary index. Minor adjusts on table name screening
format for added tests.
BUG#47777 - innodb dies with spatial pk: Failing assertion: buf <= original_buf + buf_len
Detailed revision comments:
r6178 | jyang | 2009-11-17 08:52:11 +0200 (Tue, 17 Nov 2009) | 6 lines
branches/5.0: Merge fix for bug #47777 from branches/5.1 -r6045
to bracnches/5.0. Treat the Geometry data same as Binary BLOB
in ha_innobase::store_key_val_for_row(), since the Geometry
data is stored as Binary BLOB in Innodb.
mysql client displays wrong character-set of server. When a user changes the
charset of a server, mysql client 'status' command displays wrong charset but
the command "SHOW VARIABLES LIKE "%charset%" displayed correct charset results.
The problem is only with the mysql client's 'status' command output.
In mysql client, the method mysql_store_lazy_result() returns 0 for
success and non-zero for failure. The method com_status() was using this method
wrongly. Fixed all such instances according to return value of the method
mysql_store_lazy_result().
