> ------------------------------------------------------------
> revno: 3184.3.13
> revision-id: joro@sun.com-20091019135504-e6fmhf4xyy0wdymb
> parent: joro@sun.com-20091026095557-euhe1z9oxtgkw35h
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B47788-5.1-bugteam
> timestamp: Mon 2009-10-19 16:55:04 +0300
> message:
> Bug #47788: Crash in TABLE_LIST::hide_view_error on
> 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.
> ------------------------------------------------------------
> revno: 3182 [merge]
> revision-id: ramil@mysql.com-20091018162655-z4dlolfx5s0zem8l
> parent: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx
> parent: ramil@mysql.com-20091013044327-24km05wc060ied87
> committer: Ramil Kalimullin <ramil@mysql.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Sun 2009-10-18 21:26:55 +0500
> message:
> Fix for bug#47963: Wrong results when index is used
>
> 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.
> ------------------------------------------------------------
> Use --include-merges or -n0 to see merged revisions.
> ------------------------------------------------------------
> revno: 3181
> revision-id: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx
> parent: joerg@mysql.com-20091016164025-kb4sbrggq5o7zufc
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Sat 2009-10-17 00:19:51 +0400
> message:
> Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN
>
> 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: 3148.9.6
> revision-id: martin.hansson@sun.com-20091102122407-krzh4h0i052lbwr5
> parent: davi.arnaut@sun.com-20091102112236-k3myix2xy8miyv4s
> committer: Martin Hansson <martin.hansson@sun.com>
> branch nick: 5.1bt
> timestamp: Mon 2009-11-02 13:24:07 +0100
> message:
> Bug#47925: regression of range optimizer and date comparison in 5.1.39!
>
> When a query was using a DATE or DATETIME value formatted
> using any other separator characters beside hyphen '-', a
> query with a greater-or-equal '>=' condition matching only
> the greatest value in an indexed column, the result was
> empty if index range scan was employed.
>
> The range optimizer got a new feature between 5.1.38 and
> 5.1.39 that changes a greater-or-equal condition to a
> greater-than if the value matching that in the query was not
> present in the table. But the value comparison function
> compared the dates as strings instead of dates.
>
> The bug was fixed by splitting the function
> get_date_from_str in two: One part that parses and does
> error checking. This function is now visible outside the
> module. The old get_date_from_str now calls the new
> function.
> ------------------------------------------------------------
> revno: 3148.9.3
> revision-id: azundris@mysql.com-20091029230154-jp2xqvzw2nhj9q41
> parent: azundris@mysql.com-20091027095316-54lwjr9vqkscq1ik
> committer: Tatiana A. Nurnberg <azundris@mysql.com>
> branch nick: 51-48295
> timestamp: Thu 2009-10-29 16:01:54 -0700
> message:
> Bug#48295: explain extended crash with subquery and ONLY_FULL_GROUP_BY sql_mode
>
> If an outer query is broken, a subquery might not even get set up.
> EXPLAIN EXTENDED did not expect this and merrily tried to de-ref all
> of the half-setup info.
>
> We now catch this case and print as much as we have, as it doesn't cost us
> anything (doesn't make regular execution slower).
> ------------------------------------------------------------
> revno: 3148.13.4
> revision-id: svoj@sun.com-20091102144320-0hz2ti21em510ee5
> parent: svoj@sun.com-20091102144140-8de1z6mdy5dopw3j
> committer: Sergey Vojtovich <svoj@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Mon 2009-11-02 18:43:20 +0400
> message:
> Applying InnoDB snashot 5.1-ss6129
>
> Detailed revision comments:
>
> r6051 | sunny | 2009-10-12 07:05:00 +0300 (Mon, 12 Oct 2009) | 6 lines
> branches/5.1: Ignore negative values supplied by the user when calculating the
> next value to store in dict_table_t. Setting autoincrement columns top negative
> values is undefined behavior and this change should bring the behavior of
> InnoDB closer to what users expect. Added several tests to check.
> rb://162
> ------------------------------------------------------------
> revno: 1810.3961.7
> 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: 1810.3964.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: 1810.3961.6
> 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: 1810.3959.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: 1810.3959.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: 1810.3959.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.
1. BUG#46000 - using index called GEN_CLUST_INDEX crashes server
Detailed revision comments:
r5895 | jyang | 2009-09-15 03:39:21 +0300 (Tue, 15 Sep 2009) | 5 lines
branches/5.1: Disallow creating index with the name of
"GEN_CLUST_INDEX" which is reserved for the default system
primary index. (Bug #46000) rb://149 approved by Marko Makela.
SELECT ... WHERE ... IN (NULL, ...) does full table scan,
even if the same query without the NULL uses efficient range scan.
The bugfix for the bug 18360 introduced an optimization:
if
1) all right-hand arguments of the IN function are constants
2) result types of all right argument items are compatible
enough to use the same single comparison function to
compare all of them to the left argument,
then
we can convert the right-hand list of constant items to an array
of equally-typed constant values for the further
QUICK index access etc. (see Item_func_in::fix_length_and_dec()).
The Item_null constant item objects have STRING_RESULT
result types, so, as far as Item_func_in::fix_length_and_dec()
is aware of NULLs in the right list, this improvement efficiently
optimizes IN function calls with a mixed right list of NULLs and
string constants. However, the optimization doesn't affect mixed
lists of NULLs and integers, floats etc., because there is no
unique common comparator.
New optimization has been added to ignore the result type
of NULL constants in the static analysis of mixed right-hand lists.
This is safe, because at the execution phase we care about
presence of NULLs anyway.
1. The collect_cmp_types() function has been modified to optionally
ignore NULL constants in the item list.
2. NULL-skipping code of the Item_func_in::fix_length_and_dec()
function has been modified to work not only with in_string
vectors but with in_vectors of other types.
The 'BEGIN/COMMIT/ROLLBACK' log event could be filtered out if the
database is not selected by --database option of mysqlbinlog command.
This can result in problem if there are some statements in the
transaction are not filtered out.
To fix the problem, mysqlbinlog will output 'BEGIN/ROLLBACK/COMMIT'
in regardless of the database filtering rules.
The 'BEGIN/COMMIT/ROLLBACK' log event could be filtered out if the
database is not selected by --database option of mysqlbinlog command.
This can result in problem if there are some statements in the
transaction are not filtered out.
To fix the problem, mysqlbinlog will output 'BEGIN/ROLLBACK/COMMIT'
in regardless of the database filtering rules.
Backport from 6.0 to 5.1.
Only those sync points are included, which are used in debug_sync.test.
The Debug Sync Facility allows to place synchronization points
in the code:
open_tables(...)
DEBUG_SYNC(thd, "after_open_tables");
lock_tables(...)
When activated, a sync point can
- Send a signal and/or
- Wait for a signal
Nomenclature:
- signal: A value of a global variable that persists
until overwritten by a new signal. The global
variable can also be seen as a "signal post"
or "flag mast". Then the signal is what is
attached to the "signal post" or "flag mast".
- send a signal: Assign the value (the signal) to the global
variable ("set a flag") and broadcast a
global condition to wake those waiting for
a signal.
- wait for a signal: Loop over waiting for the global condition until
the global value matches the wait-for signal.
Please find more information in the top comment in debug_sync.cc
or in the worklog entry.
The problem was that appending values to the end of an existing
ENUM or SET column was being treated as table data modification,
preventing a immediately (fast) table alteration that occurs when
only table metadata is being modified.
The cause was twofold: adding a enumeration or set members to the
end of the list of valid member values was not being considered
a "compatible" table alteration, and for SET columns, the check
was being done upon the max display length and not the underlying
(pack) length of the field.
The solution is to augment the function that checks wether two ENUM
or SET fields are compatible -- by comparing the pack lengths and
performing a limited comparison of the member values.
The bug is not related to MERGE table or TRIGGER. More correct description
would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
On PREPARE stage(see test case) we call mark_common_columns() func which
creates ON condition for NATURAL JOIN and sets appropriate
table read_set bitmaps for fields which are used in ON condition.
On EXECUTE stage mark_common_columns() is not called, we set
necessary read_set bitmaps in setup_conds(). But 'B.f1' field
is already processed and related item alredy fixed before
setup_conds() as updated field and setup_conds can not set
read_set bitmap because of that.
The fix is to set read_set bitmap for appropriate table field even
if Item_direct_view_ref item which represents a refernce to this field
is fixed.
"load data" statements were written to the binlog as a mix of the original statement
and bits recreated from parse-info. This relied on implementation details and broke
with IGNORE_SPACES and versioned comments.
We now completely resynthesize the query for LOAD DATA for binlog (which among other
things normalizes them somewhat with regard to case, spaces, etc.).
We have already parsed the query properly, so we make use of that rather
than mix-and-match string literals and parsed items.
This should make us safe with regard to versioned comments, even those
spanning multiple tokens. Also no longer affected by IGNORE_SPACES.
view definition
During SHOW CREATE VIEW there is no reason to 'anonymize'
errors that name objects that a user does not have access
to. Moreover it was inconsistently implemented. For example
base tables being referenced from a view appear to be ok,
but not views. The manual on the other hand is clear: If a
user has the privileges SELECT and SHOW VIEW, the view
definition is available to that user, period. The fix
changes the behavior to support the manual.
trigger, merge table
The problem with break statements is that they have very
local effects. Hence a break statement within the inner loop
of a nested-loops join caused execution to proceed to the
next table even though a serious error occurred. The problem
was fixed by breaking out the inner loop into its own
method. The change empowers all errors to terminate the
execution.
The errors that will now halt multi-DELETE execution
altogether are
- triggers returning errors
- handler errors
- server being killed
Invalid (old?) table or database name in logs
Problem was still not completely fixed, due to
qouting.
This is the server side only fix (in explain_filename),
the change from filename_to_tablename to use explain_filename
in the InnoDB code must be done before the bug is
fixed.
value from the index (PRIMARY)
With the fix for BUG#46760, we correctly flag the presence of row_type
only when it's actually changed and enables the FAST ALTER TABLE which was
disabled with the BUG#39200.
So the changes made by BUG#46760 makes MySQL data dictionaries to be out of
sync but they are handled already by InnoDB with this BUG#44030.
The test was originally written to handle this but we requested Innodb to
update the test as the data dictionaries were in sync after the fix for
BUG#39200.
Adjusting the innodb-autoinc testcase as mentioned in the comments.
The "socket" variable is not available on Windows even though
the --socket option can be used to specify the pipe name for
local connections that use a named pipe.
The solution is to ensure that the variable is always defined.
checksum)"
The problem was that checksum of GEOMETRY type used memory addresses
in the computation, making it un-repeatable thus useless.
(This patch is a backport from 6.0 branch)
Despite copying the value of the old table's row type
we don't always have to mark row type as being specified.
Innodb uses this to check if it can do fast ALTER TABLE
or not.
Fixed by correctly flagging the presence of row_type
only when it's actually changed.
Added a test case for 39200.
query
The fix for bug 46749 removed the check for OUTER_REF_TABLE_BIT
and substituted it for a check on the presence of
Item_ident::depended_from.
Removing it altogether was wrong : OUTER_REF_TABLE_BIT should
still be checked in addition to depended_from (because it's not
set in all cases and doesn't contradict to the check of depended_from).
Fixed by returning the old condition back as a compliment to the
new one.
1. Fixes BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc value
from the index (PRIMARY)
2. Disables the innodb-autoinc test for innodb plugin temporarily.
The testcase for this bug has different result file for InnoDB plugin.
Should add the testcase to Innodb suite with a different result file.
Detailed revision comments:
r5243 | sunny | 2009-06-04 03:17:14 +0300 (Thu, 04 Jun 2009) | 14 lines
branches/5.1: When the InnoDB and MySQL data dictionaries go out of sync, before
the bug fix we would assert on missing autoinc columns. With this fix we allow
MySQL to open the table but set the next autoinc value for the column to the
MAX value. This effectively disables the next value generation. INSERTs will
fail with a generic AUTOINC failure. However, the user should be able to
read/dump the table, set the column values explicitly, use ALTER TABLE to
set the next autoinc value and/or sync the two data dictionaries to resume
normal operations.
Fix Bug#44030 Error: (1500) Couldn't read the MAX(ID) autoinc value from the
index (PRIMARY)
rb://118
r5252 | sunny | 2009-06-04 10:16:24 +0300 (Thu, 04 Jun 2009) | 2 lines
branches/5.1: The version of the result file checked in was broken in r5243.
r5259 | vasil | 2009-06-05 10:29:16 +0300 (Fri, 05 Jun 2009) | 7 lines
branches/5.1:
Remove the word "Error" from the printout because the mysqltest suite
interprets it as an error and thus the innodb-autoinc test fails.
Approved by: Sunny (via IM)
r5466 | vasil | 2009-07-02 10:46:45 +0300 (Thu, 02 Jul 2009) | 6 lines
branches/5.1:
Adjust the failing innodb-autoinc test to conform to the latest behavior
of the MySQL code. The idea and the comment in innodb-autoinc.test come
from Sunny.
The problem is that argument buffer can be used as result buffer
and it leads to argument value change.
The fix is to use 'old buffer' as result buffer only
if first argument is not constant item.
