Fix for bug#22738 Events: After stop and start disabled events could reside in the queue

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.


sql/event_queue.cc:
  Sort the event queue in a way that the disabled events will always be
  at the end. We will use this for cleaning it, starting from the end.
  
  After recalculating times in the queue, after the scheduler has been enabled
  after disabled state, the queue should be cleaned from DISABLED events.
  The queue is sorted in a way such that the disabled events are at the end.
  Thus, we can start from the end of the queue and remove all DISABLED till we
  find the first with different state.
sql/events.cc:
  Add a comment about possible problem with replication of events,
  disabled events and server restarts.

1 files changed, 6 insertions, 1 deletions

diff --git a/sql/events.cc b/sql/events.cc
index 87385082a82..700663db7d1 100644
--- a/sql/events.cc
+++ b/sql/events.cc
@@ -1185,7 +1185,12 @@ Events::load_events_from_db(THD *thd)
     {
       /*
         If not created, a stale event - drop if immediately if
-        ON COMPLETION NOT PRESERVE
+        ON COMPLETION NOT PRESERVE.
+        XXX: This won't be replicated, thus the drop won't appear in
+             in the slave. When the slave is restarted it will drop events.
+             However, as the slave will be "out of sync", it might happen that
+             an event created on the master, after master restart, won't be
+             replicated to the slave correctly, as the create will fail there.
       */
       int rc= table->file->ha_delete_row(table->record[0]);
       if (rc)