Bug #47274 assert in open_table on CREATE TABLE <already existing>
The problem was an assertion during execution of CREATE TABLES.
This assertion would occur if INSERT DELAYED or REPLACE DELAYED
were used to update a table containing an AUTO_INCREMENT column
and if the inserted row had a user-supplied value for that column.
Any CREATE TABLE statement (including CREATE TABLE SELECT and
CREATE TABLE LIKE) trying to create the same table and
which followed the INSERT/REPLACED would cause the assertion.
The problem was only noticeable on debug builds of the server
and not present in the mysql-5.1 tree.
The cause of the problem was that the code for delayed insert did
not properly reset the TABLE->auto_increment_if_null flag after
The flag is used to indicate that a non-null value of an auto_increment field
has been provided by the user or retrieved from a current record.
Open_tables() contains an assertion that tests this flag, and this
was triggered by CREATE TABLE.
This patch fixes the problem by resetting the auto_increment_if_null
field to FALSE once INSERT/REPLACE DELAYED has updated the table,
similar to what is done already for regular INSERT statements.
Test case added to delayed.test.
mysql-test/r/loadxml.result
mysql-test/t/loadxml.test
Fixing non-deterministic test results
sql/sql_yacc.yy
Initializing fname_first using get_tok_end() instead of get_ptr().
The latter is grammar-dependant. The former is not.
columns without where/group
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.
----------------------------------------------------------
revno: 2630.2.6
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-27430
timestamp: Mon 2008-05-26 16:12:28 +0400
message:
Cover four special cases of WL#4166 with tests:
- when the query cache is disabled at the time of prepared statement
reprepare
- when long data parameters are used
- when character_set_connection != character_set_client, and a parameter
conversion takes place
- when parameter data is out of acceptable range, e.g. year 10000 is
supplied as part of MYSQL_TYPE_DATETIME value. The server is supposed
to warn in such case.
-----------------------------------------------------------
revno: 2630.2.4
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-runtime
timestamp: Fri 2008-05-23 02:42:32 +0400
message:
Bug#27430 "Crash in subquery code when in PS and table DDL changed after
PREPARE"
Add a test case for the situation with small TDC and many merge children.
from 6.0-codebase.
Bug #33629: last_day function can return null, but has 'not null' flag set for result
LAST_DAY and MAKEDATE functions are documented as
returning NULL value, but actually they was implemented
as returning NOT NULL typed values.
That caused a confusing error "ERROR 1048 (23000): Column
'...' cannot be null" on queries like:
SELECT 1 FROM (SELECT LAST_DAY('0')) a;
The problem was in incorrect handling of predicates involving
NULL as a constant value by the range optimizer.
For example, when creating a SEL_ARG node from a condition of
the form "field < const" (which would normally result in the
"NULL < field < const" SEL_ARG), the special case when "const"
is NULL was not taken into account, so "NULL < field < NULL"
was produced for the "field < NULL" condition.
As a result, SEL_ARG structures of this form could not be
further optimized which in turn could lead to incorrectly
constructed SEL_ARG trees. In particular, code assuming SEL_ARG
structures to always form a sequence of ordered disjoint
intervals could enter an infinite loop under some
circumstances.
Fixed by changing get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
Problem: using null microsecond part (e.g. "YYYY-MM-DD HH:MM:SS.0000")
in a WHERE condition may lead to wrong results due to improper
DATETIMEs comparison in some cases.
Fix: as we compare DATETIMEs as strings we must trim trailing 0's
in such cases.
not on predefined values
The default name of the PID file was constructed, as documented,
based on the hostname. This name was subsequently used as the
base for the general log file name. If the name of the PID
file was overridden in the configuration, and no explicit name
was set for the general log file, the path location for the
PID file was used also for the general log file.
A new variable, 'default_logfile_name', has been introduced. This name
is constructed based on the hostname, and is then used to
construct both the PID file and the general log file.
The general log file will now, unless explicitly set, be
located in the server data directory (as documentated in
the server docs)
Unable to reproduce crash with current version of the 5.5.0 codebase.
Test case for MyISAM/InnoDB based on the bug rapport added to
sp_trans.test.
Backport of revno: 2617.65.9.
Unable to reproduce error on current version of the 5.5.0
codebase. Test case based on the bug report added to trigger.test.
Backport of revno: 2617.52.11.
In MySQL when the mapping for space is changed to something other than
0x20 by defining a different collation, then space is not ignored when
comparing two strings.
This was happening because the function that performs the comparison
of two strings while ignoring ending spaces, was comparing the collation
value of a space with the ascii value of the ' ' character. This should
be changed to do comparison between the collated values.
Original revision in 6.0:
------------------------------------------------------------
revno: 2630.13.11
committer: Alexander Nozdrin <alik@mysql.com>
branch nick: 6.0-rt-wl4300
timestamp: Thu 2008-07-24 11:44:21 +0400
message:
A patch for WL#4300: Define privileges for tablespaces.
------------------------------------------------------------
per-file messages:
mysql-test/r/grant.result
Update result file: new columm 'Create_tablespace_priv' has been added to mysql.user.
mysql-test/r/ps.result
Update result file: new columm 'Create_tablespace_priv' has been added to mysql.user.
mysql-test/r/system_mysql_db.result
Update result file: new columm 'Create_tablespace_priv' has been added to mysql.user.
mysql-test/suite/falcon/r/falcon_tablespace_priv.result
Test case for WL#4300.
mysql-test/suite/falcon/t/falcon_tablespace_priv.test
Test case for WL#4300.
mysql-test/suite/ndb/r/ndb_dd_ddl.result
Test case for WL#4300.
mysql-test/suite/ndb/t/ndb_dd_ddl.test
Test case for WL#4300.
scripts/mysql_system_tables.sql
New columm 'Create_tablespace_priv' has been added to mysql.user.
scripts/mysql_system_tables_data.sql
'CREATE TABLESPACE' is granted by default to the root user.
scripts/mysql_system_tables_fix.sql
Grant 'CREATE TABLESPACE' privilege during system table upgrade
if a user had SUPER privilege.
sql/sql_acl.cc
Added CREATE TABLESPACE privilege.
sql/sql_acl.h
Added CREATE TABLESPACE privilege.
sql/sql_parse.cc
Check global 'CREATE TABLESPACE' privilege for the following SQL statements:
- CREATE | ALTER | DROP TABLESPACE
- CREATE | ALTER | DROP LOGFILE GROUP
sql/sql_show.cc
Added CREATE TABLESPACE privilege.
sql/sql_yacc.yy
Added CREATE TABLESPACE privilege.
low myisam_sort_buffer_size
Repair by sort (default) or parallel repair of a MyISAM table
(doesn't matter partitioned or not) as well as bulk inserts
and enable indexes some times didn't failover to repair with
key cache.
The problem was that after unsuccessful attempt, data file was
closed. Whereas repair with key cache requires open data file.
Fixed by reopening data file.
Also fixed a valgrind warning, which may appear during repair
by sort or parallel repair with certain myisam_sort_buffer_size
number of rows and length of an index entry (very dependent).
strict SQL mode
The problem was that a COMMENT longer than 64 characters
caused CREATE PROCEDURE to fail.
This patch fixed the problem by changing the COMMENT field in
mysql.proc from char(64) to text. The corresponding ROUTINE_COMMENT
field in INFORMATION_SCHEMA.ROUTINES is also changed from
varchar(64) to longtext.
mysql_system_tables.sql and mysql_system_tables_fix.sql updated.
Test case added to sp.test and affected result-files updated.
case than in corr index".
Server was unable to find existing or explicitly created supporting
index for foreign key if corresponding statement clause used field
names in case different than one used in key specification and created
yet another supporting index.
In cases when name of constraint (and thus name of generated index)
was the same as name of existing/explicitly created index this led
to duplicate key name error.
The problem was that unlike all other code Key_part_spec::operator==()
compared field names in case sensitive fashion. As result routines
responsible for getting rid of redundant generated supporting indexes
for foreign key were not working properly for versions of field names
using different cases.
Original revision in 6.0:
------------------------------------------------------------
revno: 2599.108.1
committer: Alexander Nozdrin <alik@sun.com>
branch nick: 6.0-rpl-bug40128
timestamp: Wed 2009-01-21 15:33:42 +0300
message:
Fix for Bug#40128: drop-no_root fails under windows in 6.0-rpl.
The problem was that directories with no permission (000) files
are deleted differently on UNIX and on Windows.
On UNIX, 000-permission file is deleted perfectly, but other files
are left in the directory.
On Windows, 000-permission file is not deleted, but other files
are deleted.
Also, the fix needed a change in mysqltest.c: 'chmod' directive
should return a positive error code (in order to be handled).
It's decided to return a constant '1' for all error codes
just to be OS-independent.
------------------------------------------------------------
InnoDB specified.
NO_ENGINE_SUBSTITUTION added to TRADITIONAL sql mode to prevent
silent conversions from InnoDB to MyISAM in that sql mode.
A number of test case results files updated to reflect this change.
Test added to sql_mode.test that checks that TRADITIONAL really
includes NO_ENGINE_SUBSTITUION.
"have_profiling"
1) Renamed have_community_features server system variable to
have_profiling.
2) Removed eable-community-features configure option and
ENABLE_COMMUNITY_FEATURES macro.
3) Removed COMMUNITY_SERVER macro and replaced its usage by
ENABLED_PROFILING.
Only --enable-profiling is now needed to enable profiling.
It was the only existing "community feature", so there was
no need for both configure options.
Using --enable-community-features will give a warning message
since it no longer exists.
To-number conversion warnings work differenly with CHAR
and VARCHAR sp variables.
The original revision-IDs are:
staale.smedseng@sun.com-20081124095339-2qdvzkp0rn1ljs30staale.smedseng@sun.com-20081125104611-rtxic5d12e83ag2o
The patch provides ER_TRUNCATED_WRONG_VALUE warning messages
for conversion of VARCHAR to numberic values, in line with
messages provided for CHAR conversions. Conversions are
checked for success, and the message is emitted in case
failure.
The tests are amended to accept the added warning messages,
and explicit conversion of ON/OFF values is added for
statements checking system variables. In test
rpl.rpl_switch_stm_row_mixed checking for warnings is
temporarily disabled for one statement, as this generates
warning messages for strings that vary between executions.
An ALTER TABLE statement which added a column and added
a non-partial index on it failed with:
"ERROR 1089 (HY000): Incorrect sub part key; the used
key part isn't a string, the used length is longer than
the key part, or the storage engine doesn't support unique
sub keys"
In a check introduced to fix an earlier bug (no. 26794),
to allow for indices on spatial type columns, the
test expression was flawed (a logical OR was used instead
of a logical AND), which led to this regression.
The code in question does a sanity check on the key, and
the flawed code mistakenly classified any index created
in the way specified above as a partial index. Since
many data types does not allow partial indices, the
statement would fail.
We set up DATE and TIMESTAMP differently in field-creation than we
did in field-MD creation (for CREATE). Admirably, ALTER TABLE
detected this and didn't damage any data, but it did initiate a
full copy/conversion, which we don't really need to do.
Now we describe Field and Create_field the same for those types.
As a result, ALTER TABLE that only changes meta-data (like a
field's name) no longer forces a data-copy when there needn't
be one.
says * for global allowed
The current behaviour of 'GRANT *' was changed as a part of the fix
for Bug#19022, Bug#17199 and Bug#18444. To avoid regression, we keep
the current behavior and update the documentation.
Test case added to grant.test.
covering index
When two range predicates were combined under an OR
predicate, the algorithm tried to merge overlapping ranges
into one. But the case when a range overlapped several other
ranges was not handled. This lead to
1) ranges overlapping, which gave repeated results and
2) a range that overlapped several other ranges was cut off.
Fixed by
1) Making sure that a range got an upper bound equal to the
next range with a greater minimum.
2) Removing a continue statement
lowercasing table name".
In lower_case_table_names > 0 mode some queries to I_S left entries
with incorrect key in table definition cache. This wasted memory and
caused some of the further queries to I_S to produce stale results
in cases when table definition was changed by a DDL statement.
Also in combination with similar problem in CREATE TABLE (which also
has peeked into table definition cache using non-normalized key) this
issue led to to spurious ER_TABLE_EXISTS_ERROR errors when one tried
to create a table with the same name as a previously existing but
dropped table (assuming that table name contained characters in upper
case).
This problem occured due to fact that fill_schema_table_from_frm()
was not properly normalizing (lowercasing) database and table names
which it used for lookups in table definition cache.
This fix adds proper normalization to this function. It also solves
similar problem in CREATE TABLE's code by ensuring that it uses
properly normalized version of table name when it peeks into table
definition cache instead of non-normalized one.
backport for bug#44059 from mysql-pe to mysql-5.1-bugteam
Using the partition with most rows instead of first partition
to estimate the cardinality of indexes.
is reached
Problem was bad error handling, leaving some new temporary
partitions locked and initialized and some not yet initialized
and locked, leading to a crash when trying to unlock the not
yet initialized and locked partitions
Solution was to unlock the already locked partitions, and not
include any of the new temporary partitions in later unlocks
can lead to bad memory access
Problem: Field_bit is the only field which returns INT_RESULT
and doesn't have unsigned flag. As it's not a descendant of the
Field_num, so using ((Field_num *) field_bit)->unsigned_flag may lead
to unpredictable results.
Fix: check the field type before casting.
Original revision in mysql-6.0-codebase is:
revno: 2617.31.14
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Sat 2009-03-28 11:42:55 +0300
message:
Bug#35297 SHOW CREATE EVENT does not show the DEFINER:
update test result after a merge from now.
