GitLab

will create multiple running events.

A CREATE IF NOT EXIST on an event that existed and was enabled caused
multiple instances of the event to run. Disabling the event didn't  help.
If the event was  dropped, the event stopped running, but when created
again, multiple instances of the event were still running. The only way
to get out of this situation was  to restart the server.

The problem was that Event_db_repository::create_event() didn't return
enough information to discriminate between situation when event didn't
exist and was created and when event did exist and was not created
(but a warning was emitted). As result in the latter case event
was added to in-memory queue of events second time. And this led to
unwarranted multiple executions of the same event.

The solution is to add out-parameter to Event_db_repository::create_event()
method which will signal that event was not created because it already
exists and so it should not be added to the in-memory queue.

In sql_class.cc, 'row_count', of type 'ha_rows', was used as last argument for
ER_TRUNCATED_WRONG_VALUE_FOR_FIELD which is
"Incorrect %-.32s value: '%-.128s' for column '%.192s' at row %ld".
So 'ha_rows' was used as 'long'.
On SPARC32 Solaris builds, 'long' is 4 bytes and 'ha_rows' is 'longlong' i.e. 8 bytes.
So the printf-like code was reading only the first 4 bytes.
Because the CPU is big-endian, 1LL is 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
so the first four bytes yield 0. So the warning message had "row 0" instead of
"row 1" in test outfile_loaddata.test:
-Warning	1366	Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 1
+Warning	1366	Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 0

All error-messaging functions which internally invoke some printf-life function
are potential candidate for such mistakes.
One apparently easy way to catch such mistakes is to use
ATTRIBUTE_FORMAT (from my_attribute.h).
But this works only when call site has both:
a) the format as a string literal
b) the types of arguments.
So:
  func(ER(ER_BLAH), 10);
will silently not be checked, because ER(ER_BLAH) is not known at
compile time (it is known at run-time, and depends on the chosen
language).
And
  func("%s", a va_list argument);
has the same problem, as the *real* type of arguments is not
known at this site at compile time (it's known in some caller).
Moreover,
  func(ER(ER_BLAH));
though possibly correct (if ER(ER_BLAH) has no '%' markers), will not
compile (gcc says "error: format not a string literal and no format
arguments").

Consequences:
1) ATTRIBUTE_FORMAT is here added only to functions which in practice
take "string literal" formats: "my_error_reporter" and "print_admin_msg".
2) it cannot be added to the other functions: my_error(),
push_warning_printf(), Table_check_intact::report_error(),
general_log_print().

To do a one-time check of functions listed in (2), the following
"static code analysis" has been done:
1) replace
  my_error(ER_xxx, arguments for substitution in format)
with the equivalent
  my_printf_error(ER_xxx,ER(ER_xxx), arguments for substitution in
format),
so that we have ER(ER_xxx) and the arguments *in the same call site*
2) add ATTRIBUTE_FORMAT to push_warning_printf(),
Table_check_intact::report_error(), general_log_print()
3) replace ER(xxx) with the hard-coded English text found in
errmsg.txt (like: ER(ER_UNKNOWN_ERROR) is replaced with
"Unknown error"), so that a call site has the format as string literal
4) this way, ATTRIBUTE_FORMAT can effectively do its job
5) compile, fix errors detected by ATTRIBUTE_FORMAT
6) revert steps 1-2-3.
The present patch has no compiler error when submitted again to the
static code analysis above.
It cannot catch all problems though: see Field::set_warning(), in
which a call to push_warning_printf() has a variable error
(thus, not replacable by a string literal); I checked set_warning() calls
by hand though.

See also WL 5883 for one proposal to avoid such bugs from appearing
again in the future.

The issues fixed in the patch are:
a) mismatch in types (like 'int' passed to '%ld')
b) more arguments passed than specified in the format.
This patch resolves mismatches by changing the type/number of arguments,
not by changing error messages of sql/share/errmsg.txt. The latter would be wrong,
per the following old rule: errmsg.txt must be as stable as possible; no insertions
or deletions of messages, no changes of type or number of printf-like format specifiers,
are allowed, as long as the change impacts a message already released in a GA version.
If this rule is not followed:
- Connectors, which use error message numbers, will be confused (by insertions/deletions
of messages)
- using errmsg.sys of MySQL 5.1.n with mysqld of MySQL 5.1.(n+1)
could produce wrong messages or crash; such usage can easily happen if
installing 5.1.(n+1) while /etc/my.cnf still has --language=/path/to/5.1.n/xxx;
or if copying mysqld from 5.1.(n+1) into a 5.1.n installation.
When fixing b), I have verified that the superfluous arguments were not used in the format
in the first 5.1 GA (5.1.30 'bteam@astra04-20081114162938-z8mctjp6st27uobm').
Had they been used, then passing them today, even if the message doesn't use them
anymore, would have been necessary, as explained above.

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.

            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.

removed wrongly introduced strlen calls

In RBR, DDL statement will change binlog format to non row-based
format before it is binlogged, but the binlog format was not be
restored, and then manipulating a temporary table can not reset binlog
format to row-based format rightly. So that the manipulated statement
is binlogged with statement-based format.

To fix the problem, restore the state of binlog format after the DDL
statement is binlogged.

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.
------------------------------------------------------------

added check_length optimization for I_S_NAME comparison

      
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.

If an EVENT is created without the DEFINER clause set explicitly or with it set  
to CURRENT_USER, the master and slaves become inconsistent. This issue stems from 
the fact that in both cases, the DEFINER is set to the CURRENT_USER of the current 
thread. On the master, the CURRENT_USER is the mysqld's user, while on the slave,  
the CURRENT_USER is empty for the SQL Thread which is responsible for executing 
the statement.

To fix the problem, we do what follows. If the definer is not set explicitly,  
a DEFINER clause is added when writing the query into binlog; if 'CURRENT_USER' is 
used as the DEFINER, it is replaced with the value of the current user before 
writing to binlog.

mysqld

Binlog the CREATE EVENT unless the created event been successfully dropped

Modified Query_log_event constructor to make sure that error_code
is not set to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED errors
when NOT_KILLED

The event scheduler was not designed to work in embedded mode. This
patch disables and excludes the event scheduler when the server is
compiled for embedded build.

Disabled events weren't removed from the memory queue after the scheduler has been
re-enabled. After recalculation of next execution time of an event, it might get disabled.

removed unnecessary privilege checks for I_S schema

            partitioned table

Trying INSERT DELAYED on a partitioned table, that has not been
used right before, crashes the server. When a table is used for
select or update, it is kept open for some time. This period I
mean with "right before".

Information about partitioning of a table is stored in form of
a string in the .frm file. Parsing of this string requires a
correctly set up lexical analyzer (lex). The partitioning code
uses a new temporary instance of a lex. But it does still refer
to the previously active lex. The delayd insert thread does not
initialize its lex though...

Added initialization for thd->lex before open table in the delayed
thread and at all other places where it is necessary to call
lex_start() if all tables would be partitioned and need to parse
the .frm file.

  
Changed the behaviour of the --event-scheduler option when used without an arguments. It
now turns the option on.

There actually were several problems here:
  - WRITE-lock is required to load events from the mysql.event table,
    but in the read-only mode an ordinary user can not acquire it;
  - Security_context::master_access attribute was not properly
    initialized in Security_context::init(), which led to differences
    in behavior with and without debug configure options.
  - if the server failed to load events from mysql.event, it forgot to
    close the mysql.event table, that led to the coredump, described
    in the bug report.

The patch is to fix all these problems:
  - Use the super-user to acquire WRITE-lock on the mysql.even table;
  - The WRITE-lock is acquired by the event scheduler in two cases:
    - on initial loading of events from the database;
    - when an event has been executed, so its attributes should
      be updated.
    Other cases when WRITE-lock is needed for the mysql.event table
    happen under the user account. So, nothing should be changed there
    for the read-only mode. The user is able to create/update/drop
    an event only if he is a super-user.
  - Initialize Security_context::master_access;
  - Close the mysql.event table in case something went wrong.

SHOW CREATE TABLE or SELECT FROM I_S.

This is the last patch for this bug, which depends on the big
CS patch and was pending.

The problem was that SHOW CREATE statements returned original
queries in the binary character set. That could cause the query
to be unreadable.

The fix is to use original character_set_client when sending
the original query to the client. In order to preserve the query
in mysqldump, 'binary' character set results should be set when
issuing SHOW CREATE statement. If either source or destination
character set is 'binary' , no conversion is performed.
The idea is that since the source character set is no longer
'binary', we fix the destination character set to still produce
valid dumps.

  - BUG#11986: Stored routines and triggers can fail if the code
    has a non-ascii symbol
  - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
  - BUG#19443: INFORMATION_SCHEMA does not support charsets properly
  - BUG#21249: Character set of SP-var can be ignored
  - BUG#25212: Character set of string constant is ignored (stored routines)
  - BUG#25221: Character set of string constant is ignored (triggers)

There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
   triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
   inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
   definition;

1. No query-definition-character set.

In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.

The context contains the following data:
  - client character set;
  - connection collation (character set and collation);
  - collation of the owner database;

The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).

2. Wrong mysqldump-output.

The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.

Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).

The solution is
  - to store definition queries in the original character set;
  - to change SHOW CREATE statement to output definition query in the
    binary character set (i.e. without any conversion);
  - introduce SHOW CREATE TRIGGER statement;
  - to dump special statements to switch the context to the original one
    before dumping and restore it afterwards.

Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.

3. INFORMATION_SCHEMA showed non-UTF8 strings

The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.

Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.

This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object.  Specialized SHOW CREATE statements should be
used for this.

The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).

Example:

  - original query:
    CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;

  - UTF8 query (for INFORMATION_SCHEMA):
    CREATE VIEW v1 AS SELECT 'Hello' AS c1;

 CREATE/DROP TEMPORARY TABLE + ROLLBACK on master

The transaction ability of the storage engines of
the tables on the replication master and the replication
slave must generally be the same.
When the storage engine type of the slave is 
non-transactional then transactions on the master that 
mix update of transactional and non-transactional tables
should be avoided because they will cause inconsistency of
the data between the master's transactional table and the
slave's non-transactional table.

The effect described by this bug is actually expected.
A detailed test case is added (to be merged later to
the updated rpl_ddl.test), as there was no coverage 
by the existing tests. 
Some code cleanup is also added by this change.

Bug#23631 "Events: SHOW VARIABLES doesn't work when mysql.event 
is damaged:

when there are no up-to-date system tables to support it:
 - initialize the scheduler before reporting "Ready for connections".
   This ensures that warnings, if any, are printed before "Ready for
   connections", and this message is not mangled.
 - do not abort the scheduler if there are no system tables
 - check the tables once at start up, remember the status and disable
   the scheduler if the tables are not up to date.
   If one attempts to use the scheduler with bad tables,
   issue an error message.
 - clean up the behaviour of the module under LOCK TABLES and pre-locking
   mode
 - make sure implicit commit of Events DDL works as expected.
 - add more tests


Collateral clean ups in the events code.

This patch fixes Bug#23631 Events: SHOW VARIABLES doesn't work 
when mysql.event is damaged

This patch adds code to the binlog calls for replication of the
CREATE, DROP, and UPDATE event commands. An extra gate was added 
to ensure a query with length 0 is not binlogged. This corrects 
the problem of events_scheduling and rpl_events failing on some
build machines.

to not collide with the recently introduced thread scheduler module.

A larger patch is to come, this is to exclude rudimentary changes
from it.

BUG#26429: SHOW CREATE EVENT is incorrect for an event that
           STARTS NOW()
BUG#26431: Impossible to re-create an event from backup if its
           STARTS clause is in the past
WL#3698: Events: execution in local time zone

The problem was that local times specified by the user in AT, STARTS
and ENDS of CREATE EVENT/ALTER EVENT statement were converted to UTC,
and the original time zone was forgotten.  This way, event scheduler
couldn't honor Daylight Saving Time shifts, and times shown to the
user were also in UTC.  Additionally, CREATE EVENT didn't allow times
in the past, thus preventing straightforward event restoration from
old backups.

This patch reworks event scheduler time computations, performing them
in the time zone associated with the event.  Also it allows times to
be in the past.

The patch adds time_zone column to mysql.event table.

NOTE: The patch is almost final, but the bug#9953 should be pushed
first.

This changeset adds replication of events and user-defined functions. 
There are several bug reports involved in this change:

BUG#16421, BUG#17857, BUG#20384:
This patch modifies the mysql.events table to permit the addition of
another enum value for the status column. The column now has values
of ('DISABLED','SLAVESIDE_DISABLED','ENABLED'). A status of
SLAVESIDE_DISABLED is set on the slave during replication of events.
This enables users to determine which events werereplicated from the 
master and to later enable them if they promote the slave to a master.
The CREATE, ALTER, and DROP statements are binlogged.
A new test was added for replication of events (rpl_events).

BUG#17671:
This patch modifies the code to permit logging of user-defined functions.
Note: this is the CREATE FUNCTION ... SONAME variety. A more friendly error 
message to be displayed should a replicated user-defined function not be
found in the loadable library or if the library is missing from the
slave.The CREATE andDROP statements are binlogged. A new test was added 
for replication of user-defined functions (rpl_udf). 

The patch also adds a new column to the mysql.event table named
'originator' that is used to store the server_id of the server that
the event originated on. This enables users to promote a slave to a 
master and later return the promoted slave to a slave and disable the
replicated events.

This patch implements the idea of the bug report by making Event_queue
unaware of Event_db_repository by making a higher level class - Events,
which is aware of most of all classes, responsible for passing all data
needed for adding/updating/deleting an event to/from the queue.

Introduces few new classes :
 - Event_worker_thread
 - Event_queue_element_for_exec

  Changed header to GPL version 2 only

Added missing DBUG_RETURN statements (in mysqldump.c)
Added missing enums
Fixed a lot of wrong DBUG_PRINT() statements, some of which could cause crashes
Removed usage of %lld and %p in printf strings as these are not portable or produces different results on different systems.