returns nothing
When looking for table or database names inside INFORMATION_SCHEMA
we must convert the table and database names to lowercase (just as it's
done in the rest of the server) when lowercase_table_names is non-zero.
This will allow us to find the same tables that we would find if there
is no condition.
Fixed by converting to lower case when extracting the database and
table name conditions.
Test case added.
DROP USER
RENAME USER CURRENT_USER() ...
GRANT ... TO CURRENT_USER()
REVOKE ... FROM CURRENT_USER()
ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged
as 'CURRENT_USER()', it is not expanded to the real user name. When slave
executes the log event, 'CURRENT_USER()' is expand to the user of slave
SQL thread, but SQL thread's user name always NULL. This breaks the replication.
After this patch, session's user will be written into query log events
if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.
Apart strict-aliasing warnings, fix the remaining warnings
generated by GCC 4.4.4 -Wall and -Wextra flags.
One major source of warnings was the in-house function my_bcmp
which (unconventionally) took pointers to unsigned characters
as the byte sequences to be compared. Since my_bcmp and bcmp
are deprecated functions whose only difference with memcmp is
the return value, every use of the function is replaced with
memcmp as the special return value wasn't actually being used
by any caller.
There were also various other warnings, mostly due to type
mismatches, missing return values, missing prototypes, dead
code (unreachable) and ignored return values.
and clarifies the invariant in dict_table_get_on_id().
In Mar 2007 Marko observed a crash during recovery, the crash resulted from
an UNDO operation on a system table. His solution was to acquire an X lock on
the data dictionary, this in hindsight was an overkill. It is unclear what
caused the crash, current hypothesis is that it was a memory corruption.
The X lock results in performance issues by when undoing changes due to
rollback during normal operation on regular tables.
Why the change is safe:
======================
The InnoDB code has changed since the original X lock change was made. In the
new code we always lock the data dictionary in X mode during startup when
UNDOing operations on the system tables (this is a given). This ensures that
the crash Marko observed cannot happen as long as all transactions that update
the system tables follow the standard rules by setting the appropriate DICT_OP
flag when writing the log records when they make the changes.
If transactions violate the above mentioned rule then during recovery (at
startup) the rollback code (see trx0roll.c) will not acquire the X lock
and we will see the crash again. This will however be a different bug.
During creation of the table list of
processed tables hidden I_S table 'VARIABLES'
is erroneously added into the table list.
it leads to ER_UNKNOWN_TABLE error in
TABLE_LIST::add_table_to_list() function.
The fix is to skip addition of hidden I_S
tables into the table list.
require O(#scans) memory
When an index merge operation was restarted, it would
re-allocate the Unique object controlling the duplicate row
ID elimination. Fixed by making the Unique object a member
of QUICK_INDEX_MERGE_SELECT and thus reusing it throughout
the lifetime of this object.
ha_innobase::create(): Add the local variable row_type = form->s->row_type.
Adjust it to ROW_TYPE_COMPRESSED when ROW_FORMAT is not specified or inherited
but KEY_BLOCK_SIZE is. Observe the inherited ROW_FORMAT even when it is not
explicitly specified.
innodb_bug54679.test: New test, to test the bug and to ensure that there are
no regressions. (The only difference in the test result without the patch
applied is that the first ALTER TABLE changes ROW_FORMAT to Compact.)
file .\filesort.cc, line 149 (part II)
Problem: the server didn't disregard sort order
for some zero length tuples.
Fix: skip sort order in such a case
(zero length NOT NULL string functions).
strict aliasing violations.
Post-merge fix: include my_compiler.h before my_attribute.h
as the latter will undef __attribute__ if the compiler is not
GCC. Based on the compiler version, in my_compiler.h we know
for sure whether the aligned attribute is supported. Furthermore,
undefining attribute might cause bugs if some system header
uses it.
strict aliasing violations.
Another rather noisy violation of strict aliasing rules
is the spatial code which makes use of stack-based memory
(of type Geometry_buffer) to provide placement for Geometry
objects. Although a placement new is allowed to dynamically
change the type of a object, the object returned by the
new placement was being ignored and the original stack-based
object was being casted to the new type, thus violating strict
aliasing rules.
The solution is to reorganize the code so that the object
returned by the new placement is used instead of casting the
original object. Also, to ensure that the stack-based object
is properly aligned with respect to the objects it provides
placement for, a set of compiler-dependent macros and types
are introduced so that the alignment of objects can be inquired
and specified.
Backport fixes from ndb: Rework the constructors of some static
object's to not call dbug functions since the constructors will
be called before main, and consequently, before the dbug library
is initialized.
and reverse() function
3 problems fixed :
1. The reported problem : caused by incorrect parsing of
the file as ucs data resulting in wrong length of the parsed
string. Fixed by truncating the invalid trailing bytes
(non-complete multibyte characters) when reading from the file
2. LOAD DATA when reading from a proper UCS2 file wasn't
recognizing the new line characters. Fixed by first looking
if a byte is a new line (or any other special) character before
reading it as a part of a multibyte character.
3. When using user variables to hold the column data in LOAD
DATA the character set of the user variable was set incorrectly
to the database charset. Fixed by setting it to the charset
specified by LOAD DATA (if any).
bytes_received/bytes_sent are ulonglong so they cannot be handled by the
ulong handling code in add_to_status/add_diff_to_status().
Fixed by adding code to handle these two variables in
add_to_status()/add_diff_to_status() and making sure they are not a subject
to the ulong handling code.
> ------------------------------------------------------------
> revno: 3392.1.1
> revision-id: gshchepa@mysql.com-20100521184732-0jvpzinv0uwyvr2d
> parent: sven.sandberg@sun.com-20100520153801-yyhujm1qqa4eyfn0
> committer: Gleb Shchepa <gshchepa@mysql.com>
> branch nick: 53804-5.1
> timestamp: Fri 2010-05-21 22:47:32 +0400
> message:
> Bug #53804: serious flaws in the alter database .. upgrade
> data directory name command
>
> The check_db_name function has been modified to validate tails of
> #mysql50#-prefixed database names for compliance with MySQL 5.0
> database name encoding rules (the check_table_name function call
> has been reused).
> ------------------------------------------------------------
> revno: 3386
> revision-id: sergey.glukhov@sun.com-20100518082821-yajhvbv1ghmlpu1n
> parent: aelkin@mysql.com-20100516170332-x8priwrdjwolc065
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Tue 2010-05-18 13:28:21 +0500
> message:
> Bug#48729 SELECT ... FROM INFORMATION_SCHEMA.ROUTINES causes memory to grow
> Analysis showed that in case of accessing I_S table
> ROUTINES we perform unnecessary allocations
> with get_field() function for every processed row that
> in their turn causes significant memory growth.
> the fix is to avoid use of get_field().
> ------------------------------------------------------------
> revno: 3367 [merge]
> revision-id: joro@sun.com-20100504140328-srxf3c088j2twnq6
> parent: kristofer.pettersson@sun.com-20100503172109-f9hracq5pqsaomb1
> parent: joro@sun.com-20100503151651-nakknn8amrapmdp7
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B53371-5.1-bugteam
> timestamp: Tue 2010-05-04 17:03:28 +0300
> message:
> Bug #53371: COM_FIELD_LIST can be abused to bypass table level grants.
>
> This is the 5.1 merge and extension of the fix.
> The server was happily accepting paths in table name in all places a table
> name is accepted (e.g. a SELECT). This allowed all users that have some
> privilege over some database to read all tables in all databases in all
> mysql server instances that the server file system has access to.
> Fixed by :
> 1. making sure no path elements are allowed in quoted table name when
> constructing the path (note that the path symbols are still valid in table names
> when they're properly escaped by the server).
> 2. checking the #mysql50# prefixed names the same way they're checked for
> path elements in mysql-5.0.
> ------------------------------------------------------------
> Use --include-merges or -n0 to see merged revisions.
> ------------------------------------------------------------
> revno: 3351.41.1
> revision-id: alexey.kopytov@sun.com-20100430111048-jdls6ofn4kkmpt09
> parent: sergey.glukhov@sun.com-20100329134249-03wyhzp5k92dzhcb
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: my51-bug48419
> timestamp: Fri 2010-04-30 15:10:48 +0400
> message:
> Bug #48419: another explain crash..
>
> WHERE predicates containing references to empty tables in a
> subquery were handled incorrectly by the optimizer when
> executing EXPLAIN. As a result, the optimizer could try to
> evaluate such predicates rather than just stop with
> "Impossible WHERE noticed after reading const tables" as
> it would do in a non-subquery case. This led to valgrind
> errors and crashes.
>
> Fixed the code checking the above condition so that subqueries
> are not excluded and hence are handled in the same way as top
> level SELECTs.
> ------------------------------------------------------------
> revno: 1810.3987.14
> revision-id: davi.arnaut@sun.com-20100429132816-ictyul6d75itek22
> parent: ramil@mysql.com-20100429044232-f0pkyx8fnpszf142
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 50974-5.0
> timestamp: Thu 2010-04-29 10:28:16 -0300
> message:
> Bug#50974: Server keeps receiving big (> max_allowed_packet) packets indefinitely.
>
> The server could be tricked to read packets indefinitely if it
> received a packet larger than the maximum size of one packet.
> This problem is aggravated by the fact that it can be triggered
> before authentication.
>
> The solution is to no skip big packets for non-authenticated
> sessions. If a big packet is sent before a session is authen-
> ticated, a error is returned and the connection is closed.
> ------------------------------------------------------------
> revno: 3363 [merge]
> revision-id: davi.arnaut@sun.com-20100429231819-i3anwzrdasjmezvt
> parent: davi.arnaut@sun.com-20100401131522-895y8uzvv8ag44gs
> parent: davi.arnaut@sun.com-20100429132816-ictyul6d75itek22
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: mysql-5.1-bugteam
> timestamp: Thu 2010-04-29 20:18:19 -0300
> message:
> Manual merge.
> ------------------------------------------------------------
> Use --include-merges or -n0 to see merged revisions.
> ------------------------------------------------------------
> revno: 1810.3987.13
> revision-id: ramil@mysql.com-20100429044232-f0pkyx8fnpszf142
> parent: alexey.kopytov@sun.com-20100426200600-op06qy98llzpzgl1
> committer: Ramil Kalimullin <ramil@mysql.com>
> branch nick: b53237-5.0-bugteam
> timestamp: Thu 2010-04-29 08:42:32 +0400
> message:
> Fix for bug #53237: mysql_list_fields/COM_FIELD_LIST stack smashing
>
> Problem: "COM_FIELD_LIST is an old command of the MySQL server, before there was real move to only
> SQL. Seems that the data sent to COM_FIELD_LIST( mysql_list_fields() function) is not
> checked for sanity. By sending long data for the table a buffer is overflown, which can
> be used deliberately to include code that harms".
>
> Fix: check incoming data length.
The patch did not apply cleanly:
- Line numbers are completely off, roughly it is 2030 -> 1313
- What is called "pend" in the patch, is "arg_end" in the source.
> ------------------------------------------------------------
> revno: 3351.14.47
> revision-id: marko.makela@oracle.com-20100421095033-0acvzxb8um8cms0a
> parent: marko.makela@oracle.com-20100421094032-ir4glqk46qvg2ywn
> committer: Marko Mäkelä <marko.makela@oracle.com>
> branch nick: 5.1-innodb
> timestamp: Wed 2010-04-21 12:50:33 +0300
> message:
> dtuple_convert_big_rec(): Store locally any fields whose maximum length
> is less than 256 bytes. (Bug #52745)
> Add related comments and debug assertions to the "offsets"
> functions in rem0rec.c.
> Approved by Sunny Bains
> ------------------------------------------------------------
> revno: 3351.14.50
> revision-id: marko.makela@oracle.com-20100421185359-8qaxoa2yyrpzwdd7
> parent: marko.makela@oracle.com-20100421102723-0i80uezbyu0ekj5d
> committer: Marko Mäkelä <marko.makela@oracle.com>
> branch nick: 5.1-innodb
> timestamp: Wed 2010-04-21 21:53:59 +0300
> message:
> btr_page_split_and_insert(): Avoid an infinite loop. (Bug #52964)
>
> btr_page_tuple_smaller(): New function, refactored from
> btr_page_split_and_insert().
>
> btr_page_get_split_rec(): Renamed from btr_page_get_sure_split_rec().
> Note that a NULL return may mean that the tuple is to be inserted into
> either the lower or upper page, to be determined by btr_page_tuple_smaller().
>
> btr_page_split_and_insert(): When btr_page_get_split_rec() returns NULL,
> invoke btr_page_tuple_smaller() to determine which half-page the tuple
> belongs to.
>
> Reviewed by Sunny Bains
> ------------------------------------------------------------
> revno: 3362
> revision-id: davi.arnaut@sun.com-20100401131522-895y8uzvv8ag44gs
> parent: ramil@mysql.com-20100429045409-r7r5lcyiruis15v7
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 50755-5.1
> timestamp: Thu 2010-04-01 10:15:22 -0300
> message:
> Bug#50755: Crash if stored routine def contains version comments
>
> The problem was that a syntactically invalid trigger could cause
> the server to crash when trying to list triggers. The crash would
> happen due to a mishap in the backup/restore procedure that should
> protect parser items which are not associated with the trigger. The
> backup/restore is used to isolate the parse tree (and context) of
> a statement from the load (and parsing) of a trigger. In this case,
> a error during the parsing of a trigger could cause the improper
> backup/restore sequence.
>
> The solution is to properly restore the original statement context
> before the parser is exited due to syntax errors in the trigger body.
