Add a new autoconf paremeter --{en,dis}able-community-features . The
default is disable for enterprise servers.
Though this is a 5.0 tree, it is only to be merged into the 5.0-community
tree and the global 5.1 tree, never to the 5.0-enterprise tree.
They can drop table after table names list creation and before table opening.
We open non existing table and get ER_NO_SUCH_TABLE error.
In this case we do not store the record into I_S table and clear error.
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
B-g#26600: table PROFILING in INFORMATION SCHEMA has wrong data type
B-g#27047[partial]: INFORMATION_SCHEMA table cannot have BIGINT \
fields
No Information_schema table has ever needed floating-point data
before. Transforming all floating point to a string and back to a
number causes a real data problem on Windows, where the libc may
pad the exponent with more leading zeroes than we expect and the
significant digits are truncated away.
This also makes interpreting an unimplemented type as a string into
a fatal error in debug builds. Thus, we will catch problems when we
try to use those types in new I_S tables.
The problem was that THD::db_access variable was not restored after
database switch in stored-routine-execution code.
The fix is to restore THD::db_access in this case.
Unfortunately, this fix requires additional changes,
because in prepare_schema_table(), called on the parsing stage, we checked
privileges. That was wrong according to our design, but this flaw haven't
struck so far, because it was masked. All privilege checkings must be
done on the execution stage in order to be compatible with prepared statements
and stored routines. So, this patch also contains patch for
prepare_schema_table(), which moves the checkings to the execution phase.
This patch corrects errors that occurred in a local manual merge as a result
of updating the local repository and includes changes necessary to correct
problems found during the recalculation of next execution of events in RBR.
execution breaks replication.
When a stored routine is executed, we switch current
database to the database, in which the routine
has been created. When the stored routine finishes,
we switch back to the original database.
The problem was that if the original database does not
exist (anymore) after routine execution, we raised an error.
The fix is to report a warning, and switch to the NULL database.
Bug#27047[partial]: INFORMATION_SCHEMA table cannot have BIGINT \
fields
No Information_schema table has ever needed floating-point data
before. Transforming all floating point to a string and back to a
number causes a real data problem on Windows, where the libc may
pad the exponent with more leading zeroes than we expect and the
significant digits are truncated away.
This also makes interpreting an unimplemented type as a string into
a fatal error in debug builds. Thus, we will catch problems when we
try to use those types in new I_S tables.
Made year 2000 handling more uniform
Removed year 2000 handling out from calc_days()
The above removes some bugs in date/datetimes with year between 0 and 200
Now we get a note when we insert a datetime value into a date column
For default values to CREATE, don't give errors for warning level NOTE
Fixed some compiler failures
Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
Removed duplicate typedef TIME and replaced it with MYSQL_TIME
Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
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.
Different set of conditions is used to verify
the validity of index definitions over a GEOMETRY
column in ALTER TABLE and CREATE TABLE.
The difference was on how sub-keys notion validity
is checked.
Fixed by extending the CREATE TABLE condition to
support the cases allowed in ALTER TABLE.
Made the SHOW CREATE TABLE not to display spatial
indexes using the sub-key notion.
Different set of conditions is used to verify
the validity of index definitions over a GEOMETRY
column in ALTER TABLE and CREATE TABLE.
The difference was on how sub-keys notion validity
is checked.
Fixed by extending the CREATE TABLE condition to
support the cases allowed in ALTER TABLE.
Made the SHOW CREATE TABLE not to display spatial
indexes using the sub-key notion.
The problem was that some facilities (like CONVERT_TZ() function or
server HELP statement) may require implicit access to some tables in
'mysql' database. This access was done by ordinary means of adding
such tables to the list of tables the query is going to open.
However, if we issued LOCK TABLES before that, we would get "table
was not locked" error trying to open such implicit tables.
The solution is to treat certain tables as MySQL system tables, like
we already do for mysql.proc. Such tables may be opened for reading
at any moment regardless of any locks in effect. The cost of this is
that system table may be locked for writing only together with other
system tables, it is disallowed to lock system tables for writing and
have any other lock on any other table.
After this patch the following tables are treated as MySQL system
tables:
mysql.help_category
mysql.help_keyword
mysql.help_relation
mysql.help_topic
mysql.proc (it already was)
mysql.time_zone
mysql.time_zone_leap_second
mysql.time_zone_name
mysql.time_zone_transition
mysql.time_zone_transition_type
These tables are now opened with open_system_tables_for_read() and
closed with close_system_tables(), or one table may be opened with
open_system_table_for_update() and closed with close_thread_tables()
(the latter is used for mysql.proc table, which is updated as part of
normal MySQL server operation). These functions may be used when
some tables were opened and locked already.
NOTE: online update of time zone tables is not possible during
replication, because there's no time zone cache flush neither on LOCK
TABLES, nor on FLUSH TABLES, so the master may serve stale time zone
data from cache, while on slave updated data will be loaded from the
time zone tables.
