The flag EXTRA_ACL is used in conjugation with our access checks, yet it is
not clear what impact this flag has.
This is a code clean up which replaces use of EXTRA_ACL with an explicit
function parameter.
The patch also fixes privilege checks for:
- SHOW CREATE TABLE: The new privilege requirement is any privilege on
the table-level.
- CHECKSUM TABLE: Requires SELECT on the table level.
- SHOW CREATE VIEW: Requires SHOW_VIEW and SELECT on the table level
(just as the manual claims)
- SHOW INDEX: Requires any privilege on any column combination.
EXPLAIN EXTENDED warning.
Query optimizer searches for the constant tables and optimizes them away. This
means that fields of such tables are substituted for their values and on later
phases they are treated as constants. After this constant tables are removed
from the query execution plan. Nevertheless constant tables were shown in
the EXPLAIN EXTENDED warning thus producing query that might be not an
equivalent of the original query.
Now the print_join function skips all tables that were optimized away from
printing to the EXPLAIN EXTENDED warning. If all tables were optimized away it
produces the 'FROM dual' clause.
A fix and a test case for Bug#34898 "mysql_info() reports 0 warnings
while mysql_warning_count() reports 1"
Review the patch by Chad Miller, implement review comments
(since Chad left) and push the patch.
This bug is actually not a bug. At least according to Monty.
See Bug#841 "wrong number of warnings" reported back in July 2003
and closed as "not a bug".
mysql_info() was printing the number of truncated columns, not
the number of warnings.
But since the message of mysql_info() was "Warnings: <number of truncated
columns>", people would expect to get the number
of warnings in it, not the number of truncated columns.
So a possible fix would be to change the message of mysql_info()
to say Rows changed: <n>, truncated: <m>.
Instead, put the number of warnings there. That is, remove the
feature that thd->cuted_fields (the number of truncated fields)
is exposed to the client. The number of truncated columns can be
calculated on the client, by analyzing SHOW WARNINGS output,
and in future we may remove thd->cuted_fields altogether.
So let's have one less thing to worry about.
revno: 2630.22.41
committer: Alexander Nozdrin <alik@mysql.com>
branch nick: 6.0-rt-bug39255
timestamp: Thu 2008-10-16 16:39:30 +0400
message:
A patch for Bug#39255: Stored procedures: crash if function
references nonexistent table.
The problem is not reproduced in 6.0. Adding a test case.
redefining trigger
The 'table->auto_increment_field_not_null' flag is only valid within
processing of a single row, and should be set to FALSE before
navigating to the next row, or exiting the operation.
This bug was caused by an SQL error occuring while executing a trigger
after the flag had been set, so the normal resetting was bypassed.
The table object was then returned to the table share's cache in
a dirty condition. When the table object was reused, an assert
caught that the flag was set.
This patch explicitly clears the flag on error/abort.
Backported from mysql-6.0-codebase revid: 2617.52.1
When assigning the new string value to the variable, the
Item::str_value member was used. This is not according to
the protocol. str_value is an internal member used for
temporary assignments, and is not consistently set for all
string operations. It is set for constant strings, so it would
work in these cases, but not for string functions (concat,
substr, etc.)
The correct approach is to use Item::val_str(..) to evaluate
and retrieve the string.
Backport from 6.0-codebase
6.0-codebase revno: 2617.31.17
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.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.
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.
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.
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.
