Grouping by a subquery in a query with a distinct aggregate
function lead to a wrong result (wrong and unordered
grouping values).
There are two related problems:
1) The query like this:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
FROM t1 GROUP BY aa
returned wrong result, because the outer reference "t1.a"
in the subquery was substituted with the Item_ref item.
The Item_ref item obtains data from the result_field object
that refreshes once after the end of each group. This data
is not applicable to filesort since filesort() doesn't care
about groups (and doesn't update result_field objects with
copy_fields() and so on). Also that data is not applicable
to group separation algorithm: end_send_group() checks every
record with test_if_group_changed() that evaluates Item_ref
items, but it refreshes those Item_ref-s only after the end
of group, that is a vicious circle and the grouped column
values in the output are shifted.
Fix: if
a) we grouping by a subquery and
b) that subquery has outer references to FROM list
of the grouping query,
then we substitute these outer references with
Item_direct_ref like references under aggregate
functions: Item_direct_ref obtains data directly
from the current record.
2) The query with a non-trivial grouping expression like:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
FROM t1 GROUP BY aa+0
also returned wrong result, since JOIN::exec() substitutes
references to top-level aliases in SELECT list with Item_copy
caching items. Item_copy items have same refreshing policy
as Item_ref items, so the whole groping expression with
Item_copy inside returns wrong result in filesort() and
end_send_group().
Fix: include aliased items into GROUP BY item tree instead
of Item_ref references to them.
logging is disabled
The server would hit an assertion because of a DBUG violation.
There was a missing DBUG_RETURN and instead a plain return
was used.
This patch replaces the return with DBUG_RETURN.
into slow log
While processing a statement, down the mysql_parse execution
stack, the thd->enable_slow_log can be assigned to
opt_log_slow_admin_statements, depending whether one is executing
administrative statements, such as ALTER TABLE, OPTIMIZE,
ANALYZE, etc, or not. This can have an impact on slow logging for
statements that are executed after an administrative statement
execution is completed.
When executing statements directly from the user this is fine
because, the thd->enable_slow_log is reset right at the beginning
of the dispatch_command function, ie, everytime a new statement
is set is set to execute.
On the other hand, for slave SQL thread (sql_thd) the story is a
bit different. When in SBR the sql_thd applies statements by
calling mysql_parse. Right after, it calls log_slow_statement
function to log them if they take too long. Calling mysql_parse
directly is fine, but also means that dispatch_command function
is bypassed. As a consequence, thd->enable_slow_log does not get
a chance to be reset before the next statement to be executed by
the sql_thd. If the statement just executed by the sql_thd was an
administrative statement and logging of admin statements was
disabled, this means that sql_thd->enable_slow_log will be set to
0 (disabled) from that moment on. End result: sql_thd stops
logging slow statements.
We fix this by resetting the value of sql_thd->enable_slow_log to
the value of opt_log_slow_slave_statements right after
log_slow_stement is called by the sql_thd.
To 5.x Release
Notes
=====
This is a backport of BUG#23300 into 5.1 GA.
Original cset revid (in betony):
luis.soares@sun.com-20090929140901-s4kjtl3iiyy4ls2h
Description
===========
When using replication, the slave will not log any slow query
logs queries replicated from the master, even if the
option "--log-slow-slave-statements" is set and these take more
than "log_query_time" to execute.
In order to log slow queries in replicated thread one needs to
set the --log-slow-slave-statements, so that the SQL thread is
initialized with the correct switch. Although setting this flag
correctly configures the slave thread option to log slow queries,
there is an issue with the condition that is used to check
whether to log the slow query or not. When replaying binlog
events the statement contains the SET TIMESTAMP clause which will
force the slow logging condition check to fail. Consequently, the
slow query logging will not take place.
This patch addresses this issue by removing the second condition
from the log_slow_statements as it prevents slow queries to be
binlogged and seems to be deprecated.
Original revision:
------------------------------------------------------------
revision-id: kent.boortz@sun.com-20100204182709-dw1dwpglkd5qrehb
committer: Kent Boortz <kent.boortz@sun.com>
branch nick: mysql-5.1-bugteam
timestamp: Thu 2010-02-04 19:27:09 +0100
message:
LT_INIT and LT_PREREQ was added in libtool 2.2 2008, a bit too
recent, switched back to the older AC_PROG_LIBTOOL
------------------------------------------------------------
When using MyIsam tables and processing concurrent DML
statements, the server may be sending back an OK to the client
before actually finishing the transaction commit procedure. This
has been reported before in BUG@37521 and BUG@29334.
This particular test case gets affected, because it performs the
following sequence:
connect (conn2, ...)
connection conn2;
LOAD DATA CONCURRENT ...
disconnect (conn2, ...)
connection master;
sync_slave_with_master
diff_tables
At this point diff_tables may report difference in the table
content (the master seems to be missing the conn2 rows).
To workaround this MyISAM concurrent DML statements issue and
make this test case deterministic, we wait on conn2 until the
rows inserted show up in the table. After this the test case
proceeds as normally would before this patch.
The number for MYSQL_REPLICATION_PLUGIN was shifted when backporting
because MYSQL_AUDIT_PLUGIN was not backported.
This problem is fixed by backporting only the number of audit plugin
and print an error when trying to load audit plugins. Note that
replication plugins compiled against old MYSQL_REPLICATION_PLUGIN
number will also be recognized as audit plugin and be rejected.
fails in PB sporadically)
The IO thread can concurrently access the relay log IO_CACHE
while another thread is performing an FLUSH LOGS procedure.
FLUSH LOGS closes and reopens the relay log and while doing so it
(re)initializes its IO_CACHE. During this procedure the IO_CACHE
mutex is also reinitialized, which can cause problems if some
other thread (namely the IO THREAD) is concurrently accessing it
at the time .
This patch fixes the problem by extending the interface of the
flush_master_info function to also include a second paramater,
"need_relay_log_lock", stating whether the thread should grab the
relay log lock or not before actually flushing the relay log.
Also, IO thread now calls flush_master_info with this flag set
when it flushes master info with in the event read_event loop.
Finally, we also increase loop time in rpl_heartbeat_basic test
case, so that the number of calls to flush logs doubles, stressing
this part of the code a little more.
> ------------------------------------------------------------
> revno: 2818.1.39
> revision-id: gshchepa@mysql.com-20091201102444-yw166t3audrojo9s
> parent: joro@sun.com-20091127160731-6h2fahbh4409i841
> committer: Gleb Shchepa <gshchepa@mysql.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Tue 2009-12-01 14:24:44 +0400
> message:
> Bug #38883 (reopened): thd_security_context is not thread safe, crashes?
>
> The bug 38816 changed the lock that protects THD::query from
> LOCK_thread_count to LOCK_thd_data, but didn't update the associated
> InnoDB functions.
>
> 1. The innobase_mysql_prepare_print_arbitrary_thd and the
> innobase_mysql_end_print_arbitrary_thd InnoDB functions have been
> removed, since now we have a per-thread mutex: now we don't need to wrap
> several inter-thread access tries to THD::query with a single global
> LOCK_thread_count lock, so we can simplify the code.
>
> 2. The innobase_mysql_print_thd function has been modified to lock
> LOCK_thd_data in direct way.
> ------------------------------------------------------------
> revno: 2818.1.38
> revision-id: joro@sun.com-20091127160731-6h2fahbh4409i841
> parent: joro@sun.com-20091127143622-bqfsmhhr2pqodsm2
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: fix-5.0-bugteam
> timestamp: Fri 2009-11-27 18:07:31 +0200
> message:
> Addendum to bug #48872: disable output in the test case because errors are
> dependent on the case mode
> ------------------------------------------------------------
> revno: 2818.1.35
> revision-id: joro@sun.com-20091127095944-autr58itccge4z9l
> parent: satya.bn@sun.com-20091125095925-871384fcnwwa2yqt
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B48872-5.0-bugteam
> timestamp: Fri 2009-11-27 11:59:44 +0200
> message:
> Bug #48872 : Privileges for stored functions ignored if function name
> is mixed case
>
> Transcode the procedure name to lowercase when searching for it in the
> hash. This is the missing part of the fix for bug #41049.
> ------------------------------------------------------------
> revno: 2818.1.29
> revision-id: joro@sun.com-20091118152410-j4tv22vf9xkb6sdz
> parent: kent.boortz@sun.com-20091117164924-rscth12t9a2qog1b
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: test-5.0-bugteam
> timestamp: Wed 2009-11-18 17:24:10 +0200
> message:
> Bug#48864: MySQL fails to compile on 64 bit Fedora 12
>
> Fixed 2 errors in comp_err executable :
> 1. Wrong (off by 1) length passed to my_checksum()
> 2. strmov() was used on overlapping strings. This is
> not legal according to the docs in stpcpy(). Used
> the overlap safe memmove() instead.
> ------------------------------------------------------------
> revno: 2818.1.26
> revision-id: joro@sun.com-20091109140946-07wao5od7l1vn4x1
> parent: joro@sun.com-20091110082141-ldr8p6s1joczve2j
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B48458-5.0-bugteam
> timestamp: Mon 2009-11-09 16:09:46 +0200
> message:
> Bug #48458: simple query tries to allocate enormous amount of
> memory
>
> The server was doing a bad class typecast causing setting of
> wrong value for the maximum number of items in an internal
> structure used in equality propagation.
> Fixed by not doing the wrong typecast and asserting the type
> of the Item where it should be done.
> ------------------------------------------------------------
> revno: 2818.1.19
> revision-id: kostja@sun.com-20091103165854-7di545xruez8w207
> parent: li-bing.song@sun.com-20091103090041-zj7nedx6ok5jgges
> committer: Konstantin Osipov <kostja@sun.com>
> branch nick: 5.0-41756
> timestamp: Tue 2009-11-03 19:58:54 +0300
> message:
> A fix and a test case for
> Bug#41756 "Strange error messages about locks from InnoDB".
>
> In JT_EQ_REF (join_read_key()) access method,
> don't try to unlock rows in the handler, unless certain that
> a) they were locked
> b) they are not used.
>
> Unlocking of rows is done by the logic of the nested join loop,
> and is unaware of the possible caching that the access method may
> have. This could lead to double unlocking, when a row
> was unlocked first after reading into the cache, and then
> when taken from cache, as well as to unlocking of rows which
> were actually used (but taken from cache).
>
> Delegate part of the unlocking logic to the access method,
> and in JT_EQ_REF count how many times a record was actually
> used in the join. Unlock it only if it's usage count is 0.
>
> Implemented review comments.
> ------------------------------------------------------------
> revno: 2818.1.18
> revision-id: li-bing.song@sun.com-20091103090041-zj7nedx6ok5jgges
> parent: davi.arnaut@sun.com-20091102201021-1brn7cjb1kvqg9gr
> committer: <Li-Bing.Song@sun.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Tue 2009-11-03 17:00:41 +0800
> message:
> BUG#48216 Replication fails on all slaves after upgrade to 5.0.86 on master
>
> When a sessione is closed, all temporary tables of the session are automatically
> dropped and are binlogged. But it will be binlogged with wrong database names when
> the length of the temporary tables' database names are greater than the
> length of the current database name or the current database is not set.
>
> Query_log_event's db_len is forgot to set when Query_log_event's db is set.
> This patch wrote code to set db_len immediately after db has set.
> ------------------------------------------------------------
> revno: 2818.4.1
> revision-id: alexey.kopytov@sun.com-20091030155453-0vlfwki805h9os62
> parent: joerg@mysql.com-20091016122941-rf6z0keqvmlgjfto
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: my50-bug48131
> timestamp: Fri 2009-10-30 18:54:53 +0300
> message:
> Bug #48131: crash group by with rollup, distinct, filesort,
> with temporary tables
>
> There were two problems the test case from this bug was
> triggering:
>
> 1. JOIN::rollup_init() was supposed to wrap all constant Items
> into another object for queries with the WITH ROLLUP modifier
> to ensure they are never considered as constants and therefore
> are written into temporary tables if the optimizer chooses to
> employ them for DISTINCT/GROUP BY handling.
>
> However, JOIN::rollup_init() was called before
> make_join_statistics(), so Items corresponding to fields in
> const tables could not be handled as intended, which was
> causing all kinds of problems later in the query execution. In
> particular, create_tmp_table() assumed all constant items
> except "hidden" ones to be removed earlier by remove_const()
> which led to improperly initialized Field objects for the
> temporary table being created. This is what was causing crashes
> and valgrind errors in storage engines.
>
> 2. Even when the above problem had been fixed, the query from
> the test case produced incorrect results due to some
> DISTINCT/GROUP BY optimizations being performed by the
> optimizer that are inapplicable in the WITH ROLLUP case.
>
> Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations
> when the WITH ROLLUP modifier is present, and splitting the
> const-wrapping part of JOIN::rollup_init() into a separate
> method which is now invoked after make_join_statistics() when
> the const tables are already known.
> ------------------------------------------------------------
> revno: 2818.1.13
> revision-id: joro@sun.com-20091030131543-2b23fnqckgbzvete
> parent: joro@sun.com-20091030094044-quadg0bwjy7cwqzw
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B48291-5.0-bugteam
> timestamp: Fri 2009-10-30 15:15:43 +0200
> message:
> Bug #48291 : crash with row() operator,select into @var, and
> subquery returning multiple rows
>
> Error handling was missing when handling subqueires in WHERE
> and when assigning a SELECT result to a @variable.
> This caused crash(es).
>
> Fixed by adding error handling code to both the WHERE
> condition evaluation and to assignment to an @variable.
> ------------------------------------------------------------
> revno: 2818.1.12
> revision-id: joro@sun.com-20091030094044-quadg0bwjy7cwqzw
> parent: joro@sun.com-20091029152429-ks55fhrp4lhknyij
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B48293-5.0-bugteam
> timestamp: Fri 2009-10-30 11:40:44 +0200
> message:
> Bug #48293: crash with procedure analyse, view with > 10 columns,
> having clause...
>
> The fix for bug 46184 was not very complete. It was not covering
> views using temporary tables and multiple tables in a FROM clause.
> Fixed by reverting the fix for 46184 and making a more general
> check that is checking at the right execution stage and for all
> of the non-supported cases.
> Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden.
> Updated the analyse.test and subselect.test accordingly.
> ------------------------------------------------------------
> revno: 2818.1.6
> revision-id: joro@sun.com-20091021084345-iki6z0uceieoupey
> parent: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B47780-5.0-bugteam
> timestamp: Wed 2009-10-21 11:43:45 +0300
> message:
> Bug #47780: crash when comparing GIS items from subquery
>
> 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).
> ------------------------------------------------------------
> revno: 2818.1.5
> revision-id: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e
> parent: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
> committer: Ramil Kalimullin <ramil@mysql.com>
> branch nick: b48258-5.0-bugteam
> timestamp: Fri 2009-10-23 16:26:48 +0500
> message:
> Fix for bug#48258: Assertion failed when using a spatial index
>
> 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.
> ------------------------------------------------------------
> revno: 2818.1.4
> revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
> parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka
> committer: Ramil Kalimullin <ramil@mysql.com>
> branch nick: b47019-5.0-bugteam
> timestamp: Wed 2009-10-21 14:04:08 +0500
> message:
> Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c,
> 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.
write()/read()
Sometimes stop/restart master or stop/restart salve can cause
network error, which can cause the 'invalid file descriptor
-1 in syscall write()/read()' warnings. All involved test
cases except rpl_slave_load_remove_tmpfile belong to the
kind of network error. So they are expected.
The 'rpl_slave_load_remove_tmpfile' belongs to file error,
but it is testing the file error as following code:
DBUG_EXECUTE_IF("remove_slave_load_file_before_write",
my_close(fd,MYF(0)); fd= -1; my_delete(fname, MYF(0)););
So it's expected too.
To fix the problem, add the valgrind warnings to the global
suppression list to suppress it.
path names than 99 characters, using the USTAR format of the
resulting source TAR.
To be able to specify the use of USTAR when creating the source
TAR, we needed both to update the GNU autotools version requirements
slightly, and update the initiation of the tools to use more
modern constructs.
--default-character-set and --character-set-server such
that only the first will give a deprecation warning.
Apart from that, the two options should do the same.
