Commit graph

912 commits

Author SHA1 Message Date
Alfranio Correia
c6d4915f3c BUG#53452 Inconsistent behavior of binlog_direct_non_transactional_updates with
temp table
            
This patch introduces two key changes in the replication's behavior.
            
Firstly, it reverts part of BUG#51894 which puts any update to temporary tables
into the trx-cache. Now, updates to temporary tables are handled according to
the type of their engines as a regular table.
            
Secondly, an unsafe mixed statement, (i.e. a statement that access transactional
table as well non-transactional or temporary table, and writes to any of them),
are written into the trx-cache in order to minimize errors in the execution when
the statement logging format is in use.
            
Such changes has a direct impact on which statements are classified as unsafe
statements and thus part of BUG#53259 is reverted.
2010-08-20 03:59:58 +01:00
Mattias Jonsson
2b2c7ae6de Rename of sql_alter_table -> sql_alter and sql_table_maintenance -> sql_admin 2010-08-16 16:25:23 +02:00
Mattias Jonsson
25ae81f133 Bug#49907: ALTER TABLE ... TRUNCATE PARTITION does not wait for
locks on the table

Fixing the partitioning specifics after TRUNCATE TABLE in
bug-42643 was fixed.

Reorganize of code to decrease the size of the giant switch
in mysql_execute_command, and to prepare for future parser
reengineering. Moved code into Sql_statement objects.

Updated patch according to davi's review comments.
2010-08-16 14:53:30 +02:00
Alfranio Correia
bd3aa7eb78 BUG#50312 Warnings for unsafe sub-statement not returned to client
After BUG#36649, warnings for sub-statements are cleared when a 
new sub-statement is started. This is problematic since it suppresses
warnings for unsafe statements in some cases. It is important that we
always give a warning to the client, because the user needs to know
when there is a risk that the slave goes out of sync.
                        
We fixed the problem by generating warning messages for unsafe statements
while returning from a stored procedure, function, trigger or while
executing a top level statement.
                        
We also started checking unsafeness when both performance and log tables are
used. This is necessary after the performance schema which does a distinction
between performance and log tables.
2010-08-10 12:32:54 +01:00
Alexander Nozdrin
dfc63866eb Auto-merge from mysql-trunk-merge. 2010-07-29 16:32:11 +04:00
c61ce4143c Manual merge 2010-07-29 11:24:35 +08:00
2ad690fdf8 BUG#49124 Security issue with /*!-versioned */ SQL statements on Slave
/*![:version:] Query Code */, where [:version:] is a sequence of 5 
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those 
servers whose versions are larger than the version appearing in the 
comment. It leads to a security issue when slave's version is larger 
than master's. A malicious user can improve his privileges on slaves. 
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.

This bug is fixed with the logic below: 
- To replace '!' with ' ' in the magic comments which are not applied on
  master. So they become common comments and will not be applied on slave.

- Example:
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
  will be binlogged as
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/
2010-07-29 11:00:57 +08:00
Davi Arnaut
60ab2b9283 WL#5498: Remove dead and unused source code
Remove unused macros or macro which are always defined.
2010-07-23 17:16:29 -03:00
Davi Arnaut
dd14fa18af WL#5498: Remove dead and unused source code
Remove unused variables.
2010-07-23 17:13:36 -03:00
Vladislav Vaintroub
1ef39ee2d1 Fix ~1000 warnings class/struct mismatch.
Handle this warning in the future as error, this will prevent pushing to main trees.
2010-06-22 18:40:14 +02:00
Konstantin Osipov
484351d108 Merge trunk-bugfixing -> trunk-runtime 2010-06-17 17:31:51 +04:00
Alexey Kopytov
eae3b4fe76 Manual merge from mysql-5.1-bugteam to mysql-trunk-merge.
conflicts:
   conflict      mysys/safemalloc.c
   conflict      sql/mysqld.cc
   conflict      sql/sp.cc
   conflict      sql/sql_lex.cc
   conflict      sql/sql_lex.h
   conflict      sql/sql_parse.cc
   conflict      sql/sql_prepare.cc
2010-06-11 17:48:24 +04:00
Alexey Kopytov
162e426238 Manual merge from the bugfix tree.
conflicts:
   conflict      sql/sql_parse.cc
2010-06-11 16:52:06 +04:00
Alexey Kopytov
b497e2c6b2 Manual merge from the bugfix tree.
conflicts:
   conflict      sql/sql_parse.cc
2010-06-11 14:51:21 +04:00
Davi Arnaut
d6e003545a Merge of mysql-5.1-bugteam into mysql-trunk-merge. 2010-06-10 22:30:49 -03:00
Davi Arnaut
53b8829682 Bug#42733: Type-punning warnings when compiling MySQL --
strict aliasing violations.

One somewhat major source of strict-aliasing violations and
related warnings is the SQL_LIST structure. For example,
consider its member function `link_in_list` which takes
a pointer to pointer of type T (any type) as a pointer to
pointer to unsigned char. Dereferencing this pointer, which
is done to reset the next field, violates strict-aliasing
rules and might cause problems for surrounding code that
uses the next field of the object being added to the list.

The solution is to use templates to parametrize the SQL_LIST
structure in order to deference the pointers with compatible
types. As a side bonus, it becomes possible to remove quite
a few casts related to acessing data members of SQL_LIST.
2010-06-10 17:45:22 -03:00
Magne Mahre
0cb90edfe5 Bug#20837 Apparent change of isolation level during transaction
Bug#46527 COMMIT AND CHAIN RELEASE does not make sense
Bug#53343 completion_type=1, COMMIT/ROLLBACK AND CHAIN don't 
          preserve the isolation level
Bug#53346 completion_type has strange effect in a stored 
          procedure/prepared statement

Added test cases to verify the expected behaviour of :
 SET SESSION TRANSACTION ISOLATION LEVEL, 
 SET TRANSACTION ISOLATION LEVEL,
 @@completion_type,
 COMMIT AND CHAIN,
 ROLLBACK AND CHAIN
 ..and some combinations of the above
2010-06-08 19:47:10 +02:00
Jon Olav Hauglid
1af11051bf manual merge from mysql-trunk-bugfixing
Conflicts:
Text conflict in mysql-test/r/archive.result
Contents conflict in mysql-test/r/innodb_bug38231.result
Text conflict in mysql-test/r/mdl_sync.result
Text conflict in mysql-test/suite/binlog/t/disabled.def
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_binlog_format_errors.result
Text conflict in mysql-test/t/archive.test
Contents conflict in mysql-test/t/innodb_bug38231.test
Text conflict in mysql-test/t/mdl_sync.test
Text conflict in sql/sp_head.cc
Text conflict in sql/sql_show.cc
Text conflict in sql/table.cc
Text conflict in sql/table.h
2010-06-06 13:19:29 +02:00
Alexander Nozdrin
4e633ec234 Auto-merge from mysql-trunk. 2010-05-28 09:47:58 +04:00
Dmitry Lenev
a3c080be7a Pre-requisite patch for bug #51263 "Deadlock between
transactional SELECT and ALTER TABLE ... REBUILD PARTITION".

The goal of this patch is to decouple type of metadata
lock acquired for table by open_tables() from type of
table-level lock to be acquired on it.

To achieve this we change approach to how we determine what
type of metadata lock should be acquired on table to be open.
Now instead of inferring it at open_tables() time from flags
and type of table-level lock we rely on that type of metadata
lock is properly set at parsing time and is not changed
further.
2010-05-25 16:35:01 +04:00
Alexey Kopytov
779e2a9686 Bug #42064: low memory crash when importing hex strings, in
Item_hex_string::Item_hex_string

The status of memory allocation in the Lex_input_stream (called
from the Parser_state constructor) was not checked which led to
a parser crash in case of the out-of-memory error.

The solution is to introduce new init() member function in
Parser_state and Lex_input_stream so that status of memory
allocation can be returned to the caller.
2010-05-21 15:23:48 +04:00
Alexander Nozdrin
eff442964a Manual merge from mysql-trunk.
Conflicts:
  - mysql-test/r/partition.result
  - mysql-test/r/variables_debug.result
  - mysql-test/t/partition.test
  - mysql-test/t/variables_debug.test
2010-05-20 16:35:28 +04:00
Jon Olav Hauglid
1c02ed3e67 manual merge from mysql-trunk-bugfixing 2010-05-18 14:52:51 +02:00
Alexander Nozdrin
5c4333bc85 Patch for Bug#27863 (excessive memory usage for many small queries in a
multiquery packet).

Background:

  - a query can contain multiple SQL statements;

  - the server frees resources allocated to process a query when the
    whole query is handled. In other words, resources allocated to process
    one SQL statement from a multi-statement query are freed when all SQL
    statements are handled.

The problem was that the parser allocated a buffer of size of the whole
query for each SQL statement in a multi-statement query. Thus, if a query
had many SQL-statements (so, the query was long), but each SQL statement
was short, ther parser tried to allocate huge amount of memory (number of
small SQL statements * length of the whole query).

The memory was allocated for a so-called "cpp buffer", which is intended to
store pre-processed SQL statement -- SQL text without version specific
comments.

The fix is to allocate memory for the "cpp buffer" once for all SQL
statements (once for a query).
2010-05-14 22:11:25 +04:00
Konstantin Osipov
5ac769be68 Draft patch that fixes and a sketches test cases for:
Bug#20837 Apparent change of isolation level during transaction,
Bug#46527 COMMIT AND CHAIN RELEASE does not make sense,
Bug#53343 completion_type=1, COMMIT/ROLLBACK AND CHAIN don't 
preserve the isolation level
Bug#53346 completion_type has strange effect in a stored 
procedure/prepared statement

Make thd->tx_isolation mean strictly "current transaction 
isolation level"
Make thd->variables.tx_isolation mean "current session isolation
level".
The current transaction isolation level is now established
at transaction start. If there was a SET TRANSACTION
ISOLATION LEVEL statement, the value is taken from it.
Otherwise, the session value is used.
A change in a session value, made while a transaction is active,
whereas still allowed, no longer has any effect on the
current transaction isolation level. This is an incompatible
change.
A change in a session isolation level, made while there is
no active transaction, overrides SET TRANSACTION statement,
if there was any.
Changed the impelmentation to not look at @@session.completion_type
in the parser, and thus fixed Bug#53346.
Changed the parser to not allow AND NO CHAIN RELEASE,
and thus fixed Bug#46527.
Changed the transaction API to take the current transaction
isolation level into account:
- BEGIN/COMMIT now do preserve the current transaction
isolation level if chaining is on.
- implicit commit, XA COMMIT or XA ROLLBACK or autocommit don't.
2010-05-07 20:28:59 +04:00
Konstantin Osipov
8280fdd3c3 Committing on behalf or Dmitry Lenev:
Fix for bug #46947 "Embedded SELECT without FOR UPDATE is
causing a lock", with after-review fixes.

SELECT statements with subqueries referencing InnoDB tables
were acquiring shared locks on rows in these tables when they
were executed in REPEATABLE-READ mode and with statement or
mixed mode binary logging turned on.

This was a regression which were introduced when fixing
bug 39843.

The problem was that for tables belonging to subqueries
parser set TL_READ_DEFAULT as a lock type. In cases when
statement/mixed binary logging at open_tables() time this
type of lock was converted to TL_READ_NO_INSERT lock at
open_tables() time and caused InnoDB engine to acquire
shared locks on reads from these tables. Although in some
cases such behavior was correct (e.g. for subqueries in
DELETE) in case of SELECT it has caused unnecessary locking.

This patch tries to solve this problem by rethinking our
approach to how we handle locking for SELECT and subqueries.
Now we always set TL_READ_DEFAULT lock type for all cases
when we read data. When at open_tables() time this lock
is interpreted as TL_READ_NO_INSERT or TL_READ depending
on whether this statement as a whole or call to function
which uses particular table should be written to the
binary log or not (if yes then statement should be properly
serialized with concurrent statements and stronger lock
should be acquired).

Test coverage is added for both InnoDB and MyISAM.

This patch introduces an "incompatible" change in locking
scheme for subqueries used in SELECT ... FOR UPDATE and
SELECT .. IN SHARE MODE.
In 4.1 the server would use a snapshot InnoDB read for 
subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE
statements, regardless of whether the binary log is on or off.
If the user required a different type of read (i.e. locking read),
he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE
clause for each individual subquery.
On of the patches for 5.0 broke this behaviour (which was not documented
or tested), and started to use locking reads fora all subqueries in SELECT ... 
FOR UPDATE/IN SHARE MODE. This patch restored 4.1 behaviour.
2010-04-28 14:04:11 +04:00
Alexander Nozdrin
d328d5be33 Manual merge from mysql-trunk.
Conflicts:
  - mysql-test/suite/rpl/r/rpl_stm_mixing_engines.result
2010-04-27 13:58:21 +04:00
Alexey Kopytov
ee09f97211 Manual merge of mysql-5.1-bugteam to
mysql-trunk-merge.

Conflicts:

Text conflict in sql/sql_priv.h
2010-04-19 16:09:44 +04:00
Alfranio Correia
de3e233b8a auto-merge mysql-trunk-bugfixing (local) --> mysql-trunk-bugfixing 2010-04-19 12:05:07 +01:00
Alexey Kopytov
7320a95808 Manual merge of mysql-5.1-bugteam into mysql-trunk-merge.
Conflicts:

Text conflict in mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result
Text conflict in sql/log.cc
Text conflict in sql/set_var.cc
Text conflict in sql/sql_class.cc
2010-04-03 21:35:51 +04:00
Mats Kindahl
e409d6f69c WL#5030: Split and remove mysql_priv.h
This patch:

- Moves all definitions from the mysql_priv.h file into
  header files for the component where the variable is
  defined
- Creates header files if the component lacks one
- Eliminates all include directives from mysql_priv.h
- Eliminates all circular include cycles
- Rename time.cc to sql_time.cc
- Rename mysql_priv.h to sql_priv.h
2010-03-31 16:05:33 +02:00
Alfranio Correia
4d71a007ba auto-merge mysql-trunk-bugfixing (local) --> mysql-trunk-bugfixing 2010-03-31 14:30:24 +01:00
Alfranio Correia
7827688f23 BUG#51291 Unfortunate effect around variable binlog_direct_non_transactional_updates
BUG#46364 introduced the flag binlog_direct_non_transactional_updates which
would make N-changes to be written to the binary log upon committing the
statement when "ON". On the other hand, when "OFF" the option was supposed
to mimic the behavior in 5.1. However, the implementation was not mimicking
the behavior correctly and the following bugs popped up:

  Case #1: N-changes executed within a transaction would go into
           the S-cache. When later in the same transaction a
           T-change occurs, N-changes following it were written
           to the T-cache instead of the S-cache. In some cases,
           this raises problems. For example, a
           Table_map_log_event being written initially into the
           S-cache, together with the initial N-changes, would be
           absent from the T-cache. This would log N-changes
           orphaned from a Table_map_log_event (thence discarded
           at the slave). (MIXED and ROW)

   Case #2: When rolling back a transaction, the N-changes that
            might be in the T-cache were disregarded and
            truncated along with the T-changes. (MIXED and ROW)

   Case #3: When a MIXED statement (TN) is ahead of any other
            T-changes in the transaction and it fails, it is kept
            in the T-cache until the transaction ends. This is
            not the case in 5.1 or Betony (5.5.2). In these, the
            failed TN statement would be written to the binlog at
            the same instant it had failed and not deferred until
            transaction end. (SBR)

To fix these problems, we have decided to do what follows:

   For Case #1 and #2, we circumvent them:

      1. by not letting binlog_direct_non_transactional_updates
         affect MIXED and RBR. These modes will keep the behavior
         provided by WL#2687. Although this will make Celosia to
         behave differently from 5.1, an execution will be always
         safe under such modes in the sense that slaves will never
         go out sync. In 5.1, using either MIXED or ROW while
         mixing N-statements and T-statements was not safe.

   For Case #3, we don't actually fix it. We:

      1. keep it and make all MIXED statements whether they end
         up failing or not or whether they are up front in the
         transaction or after some transactional change to always
         be stored in the T-cache. This means that it is written
         to the binary log on transaction commit/rollback only.

      2. We make the warning message even more specific about the
         MIXED statement and SBR.
2010-03-31 14:22:47 +01:00
8d22c5f3ef Bug #50095 Multi statement including CREATE EVENT causes rotten binlog entry
The log event of 'CREATE EVENT' was being binlogged with garbage
at the end of the query if 'CREATE EVENT' is followed by another SQL statement
and they were executed as one command.
for example:
    DELIMITER |;
    CREATE EVENT e1 ON EVERY DAY DO SELECT 1; SELECT 'a';
    DELIMITER ;|
When binlogging 'CREATE EVENT', we always create a new statement with definer
and write it into the log event. The new statement is made from cpp_buf(preprocessed buffer).
which is not a c string(end with '\0'), but it is copied as a c string.

In this patch, cpp_buf is copied with its length.
2010-03-28 16:37:47 +08:00
Alexander Nozdrin
04b8cb1882 Manual merge from mysql-trunk-merge.
Conflicts:
  - client/mysql.cc
  - client/mysqldump.c
  - configure.in
  - mysql-test/r/csv.result
  - mysql-test/r/func_time.result
  - mysql-test/r/show_check.result
  - mysql-test/r/sp-error.result
  - mysql-test/r/sp.result
  - mysql-test/r/sp_trans.result
  - mysql-test/r/type_blob.result
  - mysql-test/r/type_timestamp.result
  - mysql-test/r/warnings.result
  - mysql-test/suite/rpl/r/rpl_sp.result
  - sql/mysql_priv.h
  - sql/mysqld.cc
  - sql/sp.cc
  - sql/sql_base.cc
  - sql/sql_table.cc
  - sql/sql_trigger.cc
  - sql/sql_view.cc
  - sql/table.h
  - sql/share/errmsg.txt
  - mysql-test/suite/sys_vars/r/log_bin_trust_routine_creators_basic.result
2010-02-24 16:52:27 +03:00
Alfranio Correia
7194aec8ba BUG#49019 Mixing self-logging eng. and regular eng. does not switch to row in mixed mode
Reading from a self-logging engine and updating a transactional engine such as Innodb
generates changes that are written to the binary log in the statement format and may
make slaves diverge. In the mixed mode, such changes should be written to the binary
log in the row format.

Note that the issue does not happen if we mix a self-logging engine and MyIsam
as this case is caught by checking the mixture of non-transactional and transactional
engines.

So, we classify a mixed statement where one reads from NDB and writes into another 
engine as unsafe:

if (multi_engine && flags_some_set & HA_HAS_OWN_BINLOGGING)
  lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_MULTIPLE_ENGINES_AND_SELF_LOGGING_ENGINE);
2010-02-22 03:25:33 +00:00
Alexander Nozdrin
6c32fa7357 Manual merge from mysql-next-mr.
Conflicts:
  - sql/log_event.cc
  - sql/sql_class.h
2010-02-15 14:16:49 +03:00
Alexey Kopytov
017c969896 Manual merge of mysql-5.1-bugteam into mysql-trunk-merge.
Conflicts:

Text conflict in .bzr-mysql/default.conf
Text conflict in mysql-test/suite/rpl/r/rpl_slow_query_log.result
Text conflict in mysql-test/suite/rpl/t/rpl_slow_query_log.test
Conflict adding files to server-tools.  Created directory.
Conflict because server-tools is not versioned, but has versioned children.  Versioned directory.
Conflict adding files to server-tools/instance-manager.  Created directory.
Conflict because server-tools/instance-manager is not versioned, but has versioned children.  Versioned directory.
Contents conflict in server-tools/instance-manager/options.cc
Text conflict in sql/mysqld.cc
2010-02-09 12:59:38 +05:00
Gleb Shchepa
57e5f8487f Bug #45640: optimizer bug produces wrong results
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.
2010-02-06 23:54:30 +04:00
Marc Alff
3630d78e6c Merge mysql-next-mr-marc --> mysql-next-mr-bugfixing 2010-02-05 09:56:55 -07:00
Konstantin Osipov
ad0f1f8021 Merge next-mr -> next-4284. 2010-02-05 01:08:08 +03:00
Alexander Nozdrin
31ba3bf5cb Manual merge from mysql-5.1-bugteam.
Conflicts:
  - mysql-test/collections/default.experimental
  - mysql-test/suite/rpl/r/rpl_sp.result
2010-02-03 17:01:48 +03:00
Konstantin Osipov
0ce6d93f85 Merge next-mr -> next-4284. 2010-02-03 03:06:42 +03:00
Alexander Nozdrin
f392eddabc Revert a patch for Bug#48231, which introduced valgrind warnings.
Original revision:
------------------------------------------------------------
revision-id: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x
parent: joro@sun.com-20100129145427-0n79l9hnk0q43ajk
committer: <Li-Bing.Song@sun.com>
branch nick: mysql-5.1-bugteam
timestamp: Sat 2010-01-30 20:49:25 +0800
message:
  Bug #48321  CURRENT_USER() incorrectly replicated for DROP/RENAME USER;
              REVOKE/GRANT; ALTER EVENT.
  
  The following statements support the CURRENT_USER() where a user is needed.
    DROP USER 
    RENAME USER CURRENT_USER() ...
    GRANT ... TO CURRENT_USER()
    REVOKE ... FROM CURRENT_USER()
    ALTER DEFINER = CURRENT_USER() EVENT
  but, 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, All above statements are rewritten when they are binlogged.
  The CURRENT_USER() is expanded to the real user's name and host.
------------------------------------------------------------
2010-02-02 16:38:44 +03:00
Alexander Nozdrin
85c54dddc7 Manual merge from mysql-5.1-bugteam.
Conflicts:
  - mysql-test/collections/default.experimental
  - mysql-test/suite/rpl/r/rpl_binlog_grant.result
  - mysql-test/suite/rpl/r/rpl_sp.result
  - mysql-test/suite/rpl/t/rpl_binlog_grant.test
  - mysql-test/suite/rpl/t/rpl_get_master_version_and_clock.test
2010-01-30 22:13:36 +03:00
788c28aceb Bug #48321 CURRENT_USER() incorrectly replicated for DROP/RENAME USER;
REVOKE/GRANT; ALTER EVENT.

The following statements support the CURRENT_USER() where a user is needed.
  DROP USER 
  RENAME USER CURRENT_USER() ...
  GRANT ... TO CURRENT_USER()
  REVOKE ... FROM CURRENT_USER()
  ALTER DEFINER = CURRENT_USER() EVENT
but, 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, All above statements are rewritten when they are binlogged.
The CURRENT_USER() is expanded to the real user's name and host.
2010-01-30 20:49:25 +08:00
Andrei Elkin
7db8e76471 Bug #50192 Strange effect in replication test, trigger, auto_increment
The auto-inc unsafe warning makes sense even though it's just
one auto-inc table could be involved via a trigger or a stored
function.
However its content was not updated by bug@45677 fixes continuing to mention
two tables whereas the fixes refined semantics of replication of auto_increment 
in stored routine.

Fixed with updating the error message, renaming the error and an internal unsafe-condition 
constants.

A documentation notice
======================

      Inserting into an autoincrement column in a stored function or a trigger
      is unsafe for replication.
      Even with just one autoincrement column, if the routine is invoked more than 
      once slave is not guaranteed to execute the statement graph same way as 
      the master.
      And since it's impossible to estimate how many times a routine can be invoked at 
      the query pre-execution phase (see lock_tables), the statement is marked
      pessimistically unsafe.
2010-01-29 15:55:35 +02:00
Marc Alff
4428409ddb Bug#34455 Ambiguous foreign keys syntax is accepted
Backport from 6.0 to 5.5
2010-01-25 04:55:31 -07:00
b805e3d4d6 Manual merge from next-mr. 2010-01-12 20:07:09 +08:00
Alfranio Correia
6f7929b143 merge mysql-5.1-rep+2-delivery1 --> mysql-5.1-rpl-merge
Conflicts:

Text conflict in .bzr-mysql/default.conf
Text conflict in mysql-test/extra/rpl_tests/rpl_loaddata.test
Text conflict in mysql-test/r/mysqlbinlog2.result
Text conflict in mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
Text conflict in mysql-test/suite/binlog/r/binlog_unsafe.result
Text conflict in mysql-test/suite/rpl/r/rpl_insert_id.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result
Text conflict in mysql-test/suite/rpl/r/rpl_udf.result
Text conflict in mysql-test/suite/rpl/t/rpl_slow_query_log.test
Text conflict in sql/field.h
Text conflict in sql/log.cc
Text conflict in sql/log_event.cc
Text conflict in sql/log_event_old.cc
Text conflict in sql/mysql_priv.h
Text conflict in sql/share/errmsg.txt
Text conflict in sql/sp.cc
Text conflict in sql/sql_acl.cc
Text conflict in sql/sql_base.cc
Text conflict in sql/sql_class.h
Text conflict in sql/sql_db.cc
Text conflict in sql/sql_delete.cc
Text conflict in sql/sql_insert.cc
Text conflict in sql/sql_lex.cc
Text conflict in sql/sql_lex.h
Text conflict in sql/sql_load.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_update.cc
Text conflict in sql/sql_view.cc
Conflict adding files to storage/innobase.  Created directory.
Conflict because storage/innobase is not versioned, but has versioned children.  Versioned directory.
Conflict adding file storage/innobase.  Moved existing file to storage/innobase.moved.
Conflict adding files to storage/innobase/handler.  Created directory.
Conflict because storage/innobase/handler is not versioned, but has versioned children.  Versioned directory.
Contents conflict in storage/innobase/handler/ha_innodb.cc
2010-01-07 15:39:11 +00:00