When the query cache is disabled, the server shouldn't attempt to take the
query cache mutex.
By using the command line option --query_cache_type=0, the user can disable
(backport from mysql-pe)
XA START may cause assertion failure/server crash when it is called
after unilateral roll back issued by the Resource Manager (both
in regular transaction and after XA transaction).
The problem was that rm_error variable wasn't set/reset properly.
Bug#46539 Various crashes on INSERT IGNORE SELECT + SELECT FOR UPDATE.
If a transaction was rolled back inside InnoDB due to a deadlock
or lock wait timeout, and the statement had IGNORE clause,
the server could crash at the end of the statement or on shutdown.
This was caused by the error handling infrastructure's attempt to
ignore a non-ignorable error.
When a transaction rollback request is raised, switch off
current_select->no_error flag, so that the following error
won't be ignored.
Instead, we could add !thd->is_fatal_sub_stmt_error to
my_message_sql(), but since in write_record() we switch
off no_error, the same approach is used in
thd_mark_transaction_to_rollback().
@todo: call thd_mark_transaction_to_rollback() from
handler::print_error(), then we can easily make sure
that the error reported by print_error is not ignored.
Item_sum::set_aggregator() may be called multiple times during query preparation.
On subsequent calls: verify that the aggregator type is the same,
and re-use the existing Aggregator.
binlog, replication aborts
In SBR or MBR, the schema name is not being written to the binlog
when executing a LOAD DATA statement. This becomes a problem when
the current database (lets call it db1) is different from the
table's schema (lets call it db2). For instance, take the
following statements:
use db1;
load data local infile 'infile.txt' into table db2.t
Should this statement be logged without t's schema (db2), when
replaying it, one can get db1.t populated instead of db2.t (if
db1.t exists). On the other hand, if there is no db1.t at all,
replication will stop.
We fix this by always logging the table (in load file) with fully
qualified name when its schema is different from the current
database or when no default database was selected.
"What do you mean, there's a bug? There isn't even code!"
There was some token code for plug-in variables of the SET type,
but clearly this never worked, or was subject to massive bit rot
since. Bug-fixes ... fail-safes ... tests -- fais au mieux, mon chou!
Problem 1:
column_priv_hash uses utf8_general_ci collation
for the key comparison. The key consists of user name,
db name and table name. Thus user with privileges on table t1
is able to perform the same operation on T1
(the similar situation with user name & db name, see acl_cache).
So collation which is used for column_priv_hash and acl_cache
should be case sensitive.
The fix:
replace system_charset_info with my_charset_utf8_bin for
column_priv_hash and acl_cache
Problem 2:
The same situation with proc_priv_hash, func_priv_hash,
the only difference is that Routine name is case insensitive.
So the fix is to use my_charset_utf8_bin for
proc_priv_hash & func_priv_hash and convert routine name into lower
case before writing the element into the hash and
before looking up the key.
Additional fix: mysql.procs_priv Routine_name field collation
is changed to utf8_general_ci.
It's necessary for REVOKE command
(to find a field by routine hash element values).
Note:
It's safe for lower-case-table-names mode too because
db name & table name are converted into lower case
(see GRANT_NAME::GRANT_NAME).
This assertion would occur if UPDATE was used to update multiple
tables containing an AUTO_INCREMENT column and if the inserted
row had a user-supplied value for that column. The assertion
could then be triggered by the next statement.
The problem was only noticeable on debug builds of the server.
The cause of the problem was that the code for multi update did
not properly reset the TABLE->auto_increment_if_null flag after update.
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 in this case by ALTER TABLE.
This patch fixes the problem by resetting the auto_increment_if_null
field to FALSE once a row has been updated.
This bug is similar to Bug#47274, but for multi update rather
than INSERT DELAYED.
Test case added to update.test.
Problem: involving a spatial index for "non-spatial" queries
(that don't containt MBRXXX() functions) may lead to failed assert.
Fix: don't use spatial indexes in such cases.
Original revision:
------------------------------------------------------------
revno: 2801.10.16
committer: Vladislav Vaintroub <vvaintroub@mysql.com>
branch nick: mysql-azalea-bugfixing
timestamp: Mon 2009-08-10 13:26:23 +0200
message:
Bug #46267 Shutdown with idle connection crash the server.
The crash happens when mysqld logs a warning. The macro
ER() used in sql_print_warning references thread local storage
variable via current_thd(), to output the warning in "current
user language". However, for the shutdown thread,
current_thd() will return NULL, and mysqld will crash while
derefencing NULL pointer.
Solution: get error mesage text with ER_DEFAULT() macro
instead of ER(), this does not current_thd() and will output
errors in default language.
------------------------------------------------------------
Conflicts
=========
Text conflict in .bzr-mysql/default.conf
Text conflict in libmysqld/CMakeLists.txt
Text conflict in libmysqld/Makefile.am
Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/extra/rpl_tests/rpl_row_sp006.test
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata_fatal.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_create_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_log.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_circular_simplex.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_sp006.result
Text conflict in mysql-test/t/mysqlbinlog.test
Text conflict in sql/CMakeLists.txt
Text conflict in sql/Makefile.am
Text conflict in sql/log_event_old.cc
Text conflict in sql/rpl_rli.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_binlog.cc
Text conflict in sql/sql_lex.h
21 conflicts encountered.
NOTE
====
mysql-5.1-rpl-merge has been made a mirror of mysql-next-mr:
- "mysql-5.1-rpl-merge$ bzr pull ../mysql-next-mr"
This is the first cset (merge/...) committed after pulling
from mysql-next-mr.
to 5.1 partially. This patch brings what was left to mysql-next-mr.
Original revisions in 6.0:
------------------------------------------------------------
revno: 2617.31.26
committer: Alexander Nozdrin <alik@sun.com>
branch nick: 6.0-rt-bug43138.3
timestamp: Thu 2009-04-30 19:31:30 +0400
message:
Fix for Bug#43138: DROP DATABASE failure does not clean up message list.
The problem was that the high-level function mysql_rm_db() invoked
low-level mysql_rm_table_part2(), which reported low-level error
(Unknown table) if SE refused to delete a table. Also when
mysql_rm_table_part2() reported an error, it didn't add corresponding
warning into the list (because it is used from other places where such
behaviour is required).
The fix is to
1. Remove no_warnings_for_error usage from sql_table.cc
2. Improve internal error handler support in THD, so that
a stack of error handlers is allowed.
3. Create an internal error handler (Drop_table_error_handler)
to silence useless warnings.
4. Use the handler in DROP DATABASE and DROP TABLE statements.
------------------------------------------------------------
revno: 2617.69.38
committer: Alexander Nozdrin <alik@sun.com>
branch nick: mysql-next-bugfixing-bug37431
timestamp: Mon 2009-08-24 21:52:09 +0400
message:
A test case for Bug#37431 (DROP TABLE does not report errors correctly).
------------------------------------------------------------
revno: 2617.31.29
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-6.0-runtime
timestamp: Fri 2009-05-01 17:37:34 +0400
message:
Follow-up for fix for bug "Bug#43138: DROP DATABASE failure
does not clean up message list".
Fixed drop.test failure under non-debug server by moving part
of test dependent on debug-only feature to separate .test file,
which won't be run for non-debug versions of server.
------------------------------------------------------------
revno: 2617.45.17
committer: Sergei Golubchik <serg@mysql.com>
branch nick: 6.0-maria
timestamp: Wed 2009-05-13 20:08:58 +0200
message:
followup for bug#43138
if delete fails with a permission denied error, we want to show it
------------------------------------------------------------
The patch was backported to 5.1 in scope of Bug#42364 by
the following revision:
------------------------------------------------------------
revno: 2497.975.3
committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
branch nick: mysql-5.1-bugteam
timestamp: Fri 2009-07-03 13:22:06 +0500
message:
Bug#42364 SHOW ERRORS returns empty resultset after dropping non existent table
enabled message storing into error message list
for 'drop table' command
------------------------------------------------------------
allows SHOW CREATE TABLE) from 6.0. Original revisions:
------------------------------------------------------------
revno: 2617.31.8
committer: Alexander Nozdrin <alik@sun.com>
branch nick: 6.0-rt-bug38347
timestamp: Thu 2009-03-26 09:08:24 +0300
message:
Patch for Bug#38347: ALTER ROUTINE privilege allows SHOW CREATE TABLE.
If a user has any of the following privileges for a table (or the database
if the table), he should be able to issue SHOW CREATE TABLE for the table:
- CREATE
- DROP
- ALTER
- DELETE
- INDEX
- INSERT
- SELECT
- UPDATE
- TRIGGER
- REFERENCES
- GRANT OPTION
- CREATE VIEW
- SHOW VIEW
Any other privilege (even SUPER) should not allow SHOW CREATE TABLE.
------------------------------------------------------------
revno: 2617.31.11
committer: Alexander Nozdrin <alik@sun.com>
branch nick: 6.0-rt
timestamp: Fri 2009-03-27 21:36:34 +0300
message:
Additional patch for Bug#38347 (ALTER ROUTINE privilege
allows SHOW CREATE TABLE).
The problem was that information_schema.test,
information_schema_parameters.test and information_schema_routines.test
failed with the first patch. That happened due to limitation in check_access():
it allows only SELECT_ACL privilege for INFORMATION_SCHEMA tables.
The patch is to request only SELECT_ACL privilege for INFORMATION_SCHEMA tables.
------------------------------------------------------------
2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
some other minor revisions.
This patch implements:
WL#4264 "Backup: Stabilize Service Interface" -- all the
server prerequisites except si_objects.{h,cc} themselves (they can
be just copied over, when needed).
WL#4435: Support OUT-parameters in prepared statements.
(and all issues in the initial patches for these two
tasks, that were discovered in pushbuild and during testing).
Bug#39519: mysql_stmt_close() should flush all data
associated with the statement.
After execution of a prepared statement, send OUT parameters of the invoked
stored procedure, if any, to the client.
When using the binary protocol, send the parameters in an additional result
set over the wire. When using the text protocol, assign out parameters to
the user variables from the CALL(@var1, @var2, ...) specification.
The following refactoring has been made:
- Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
- A new Protocol::send_result_set_row() was introduced to incapsulate
common functionality for sending row data.
- Signature of Protocol::prepare_for_send() was changed: this operation
does not need a list of items, the number of items is fully sufficient.
The following backward incompatible changes have been made:
- CLIENT_MULTI_RESULTS is now enabled by default in the client;
- CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
------------------------------------------------------------
revno: 2476.714.9
committer: markleith@medusa.mysql.com
timestamp: Mon 2007-09-03 23:18:50 +0100
message:
Bug#25822 / WL#3953 - Log Access Denied errors for bad passwords in the error log
Added logging of Access Denied messages on failed new connections to the
error log when log-warnings = 2.
This allows a user to log these messages without having to incur the overhead
of using the general query log on production systems.
------------------------------------------------------------
line 138 when forcing a spatial index
Problem: "Spatial indexes can be involved in the search
for queries that use a function such as MBRContains()
or MBRWithin() in the WHERE clause".
Using spatial indexes for JOINs with =, <=> etc.
predicates is incorrect.
Fix: disable spatial indexes for such queries.
If the first argument to GeomFromWKB function is a geometry
field then the function just returns its value.
However in doing so it's not preserving first argument's
null_value flag and this causes unexpected null value to
be returned to the calling function.
Fixed by updating the null_value of the GeomFromWKB function
in such cases (and all other cases that return a NULL e.g.
because of not enough memory for the return buffer).
file
Issuing 'FLUSH LOGS' does not close and reopen indexfile.
Instead a SEEK_SET is performed.
This patch makes index file to be closed and reopened whenever a
rotation happens (FLUSH LOGS is issued or binary log exceeds
maximum configured size).
During insert, we are not reading the rows in a referring table but
instead using the last read row that happens to be in table->record[0].
Now INSERT into such view is denied.
grants are reapplied.
After renaming a user and trying to re-apply grants results in additional
grants.
This is because we use username as part of the key for GRANT_TABLE structure.
When the user is renamed, we only change the username stored and the hash key
still contains the old user name and this results in the extra privileges
Fixed by rebuilding the hash key and updating the column_priv_hash structure
when the user is renamed
If a thread is killed in the server, we throw "shutdown" only if one is actually in
progress; otherwise, we throw "query interrupted".
Control-C in the mysql command-line client is "incremental" now.
First Control-C sends KILL QUERY (when connected to 5.0+ server, otherwise, see next)
Next Control-C sends KILL CONNECTION
Next Control-C aborts client.
As the first two steps only pertain to an existing query,
Control-C will abort the client right away if no query is running.
client will give more detailed/consistent feedback on Control-C now.
UPDATE + VIEW + SP + MERGE + ALTER
When cleaning up the stored procedure's internal
structures the flag to ignore the errors for
INSERT/UPDATE IGNORE was not cleaned up.
As a result error ignoring was on during name
resolution. And this is an abnormal situation : the
SELECT_LEX flag can be on only during query execution.
Fixed by correctly cleaning up the SELECT_LEX flag
when reusing the SELECT_LEX in a second execution.
SP variables
A function call may end without throwing an error or without setting
the return value. This can happen when e.g. an error occurs while
calculating the return value.
Fixed by setting the value to NULL when error occurs during evaluation
of an expression.
BUG#38049 "incorrect rows estimations with references from preceding table"
(from revid:sergefp@mysql.com-20090126194259-ue20il3qro529l4d).
Compared to 6.0 where EXPLAIN indicates "Using index condition", here in join_optimizer.result
we see "Using where"; it's normal; 6.0 shows the same if disabling Index Condition Pushdown.
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.
Adding @@session and @@global prefixes to a
declared variable in a stored procedure the server
would lead to a crash.
The reason was that during the parsing of the
syntactic rule 'option_value' an uninitialized
set_var object was pushed to the parameter stack
of the SET statement. The parent rule
'option_type_value' interpreted the existence of
variables on the parameter stack as an assignment
and wrapped it in a sp_instr_set object.
As the procedure later was executed an attempt
was made to run the method 'check()' on an
uninitialized member object (NULL value) belonging
to the previously created but uninitialized object.
Problem: using null microsecond part in a WHERE condition
(e.g. WHERE date_time_field <= "YYYY-MM-DD HH:MM:SS.0000")
may lead to wrong results due to improper DATETIMEs
comparison in some cases.
Fix: comparing DATETIMEs as strings we must trim trailing 0's
in such cases.
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.
revno: 2617.68.41
committer: Alexander Nozdrin <alik@sun.com>
branch nick: mysql-6.0-codebase-bugfixing-bug47421
timestamp: Wed 2009-09-23 17:48:11 +0400
message:
A patch for Bug#47421 (Server crash from -
SELECT SUM ( DISTINCT <char_column>) in azalea).
The problem was that DBUG_RETURN() macro should have been
used instead the 'return' operator.
----------------------------------------------------------
revno: 2630.13.6
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-3288
timestamp: Fri 2008-07-11 20:22:44 +0400
message:
WL#3288, step 1: ensure that the SQL layer always closes an open
cursor (rnd or index read) before closing a handler.
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.
view that has Group By
When SELECT'ing from a view that mentions another,
materialized, view, access was being denied. The issue was
resolved by lifting a special case which avoided such access
checking in check_single_table_access. In the past, this was
necessary since if such a check were performed, the error
message would be downgraded to a warning in the case of SHOW
CREATE VIEW. The downgrading of errors was meant to handle
only that scenario, but could not distinguish the two as it
read only the error messages.
The special case was needed in the fix of bug no 36086.
Before that, views were confused with derived tables.
After bug no 35996 was fixed, the manipulation of errors
during SHOW CREATE VIEW execution is not dependent on the
actual error messages in the queue, it rather looks at the
actual cause of the error and takes appropriate
action. Hence the aforementioned special case is now
superfluous and the bug is fixed.
Implemented the server infrastructure for the fix:
1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of
thd_query()
2. Did some encapsulation in THD : aggregated thd_query and
thd_query_length into a LEX_STRING and made accessor and mutator
methods for easy code updating.
3. Updated the server code to use the new methods where applicable.
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
The fix for Bug #38124 introuced a bug. If the value given
for a set_var exceeded the length of the temporary buffer,
we would read behind the end of the buffer. Using
c_ptr_safe(), instead of c_ptr(), ensures that we won't
read beyond the buffer limit
mysql-6.0-codebase revid: 2617.44.1
get_table_share, drop_open_table
In the partition handler code, LOCK_open and share->LOCK_ha_data
are acquired in the wrong order in certain cases. When doing a
multi-row INSERT (i.e a INSERT..SELECT) in a table with auto-
increment column(s). the increments must be in a monotonically
continuous increasing sequence (i.e it can't have "holes"). To
achieve this, a lock is held for the duration of the operation.
share->LOCK_ha_data was used for this purpose.
Whenever there was a need to open a view _during_ the operation
(views are not currently pre-opened the way tables are), and
LOCK_open was grabbed, a deadlock could occur. share->LOCK_ha_data
is other places used _while_ holding LOCK_open.
A new mutex was introduced in the HA_DATA_PARTITION structure,
for exclusive use of the autoincrement data fields, so we don't
need to overload the use of LOCK_ha_data here.
A module test case has not been supplied, since the problem occurs
as a result of a race condition, and testing for this condition
is thus not deterministic. Testing for it could be done by
setting up a test case as described in the bug report.
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
Fix a regression that crept in when downporting Windows improvements.
Instead of a shutdown thread, another thread that handledsocket connection was created.
Temporary tables may set join->group to 0 even though there is
grouping. Also need to test if sum_func_count>0 when JOIN::exec()
decides whether to present results in a grouped manner.
----------------------------------------------------------
revno: 2630.28.1
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Thu 2008-10-23 15:23:44 +0400
message:
Bug#32738 "mysqld: Two slow log option/variable descriptions are
inaccurate"
Update option description per suggestion from the documentation team.
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.
----------------------------------------------------------
revno: 2630.22.8
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-runtime
timestamp: Sun 2008-08-10 18:49:52 +0400
message:
Get rid of typedef struct for the most commonly used types:
TABLE, TABLE_SHARE, LEX. This simplifies use of tags
and forward declarations.
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.
Use ev_offset instead of 1 as the packet header offset when getting
log position from events for heartbeat
call reset_transmit_packet before calling send_heartbeat_event
The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
id stored inside the events of the BINLOG statement rather than the id of the running
server.
Fix by rearranging code a bit so that only relevant parts of the code are executed by
the BINLOG statement, and the server_id of the server executing the statements will
not be overrided by the server_id stored in the 'format description BINLOG statement'.
revno: 2630.2.16
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-runtime
timestamp: Fri 2008-06-27 13:26:03 +0400
message:
Fix max_user_connections_func failure on Solaris.
A connection that failed to log in due to a resource limit could
be returned to the thread pool with a dangling link to user_connect
structure of an old user. Later on it could be authenticated
to a user that doesn't have a resource limit, so this dangling
link won't be reset. --pool-of-threads mode made the situation
easy to reproduce, and thus highlighted a bug that has been
around forever.
Make sure there are no dangling links.
----------------------------------------------------------
revno: 2617.1.12
committer: kostja@bodhi.(none)
timestamp: Sun 2008-04-20 11:18:52 +0400
message:
A fix for Bug#32771 "events_bugs.test fails randomly".
In Event_scheduler::stop(), which may be called from destructor,
wait synchronously for the parallel Event_scheduler::stop() to
complete before returning. This fixes a race between
MySQL shutdown thread and the scheduler thread who could call
stop() in parallel.
local storage for query cache).
We need more than one pointer in a thread to
represent the query cache and net->query_cache_query can not be used
any more (due to ABI compatibility issues and to different life
time of NET and THD).
This is a backport of the following patch from 6.0:
----------------------------------------------------------
revno: 2476.1157.2
committer: kostja@bodhi.(none)
timestamp: Sat 2007-06-16 13:29:24 +0400
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)
