Andrei Elkin <andrei.elkin@mariadb.com> writes:

Kristian Nielsen via developers <developers@lists.mariadb.org> writes:

...

The already-started instance of the event happily continues to run after being dropped. I wonder if that's a bug, or if the documentation is wrong?

To this question, I vaguely remember discussions about this matter which must've concuded in that it's not a bug when the scheduler races ahead of DROP EVENT to launch a piece of job, like INSERT in this case.

Aha, I see. Following up on this, I found this comment in the code Stops the scheduler (again). Waits for acknowledgement from the scheduler that it has stopped - synchronous stopping. Already running events will not be stopped. If the user needs them stopped manual intervention is needed. So then the behaviour seen in the test case is expected, and just fixing the test to handle the possible race should be correct. I also see in the code that the thread running the events starts by loading the event definition from the system tables (mysql.event ...), db_repository->load_named_event(). So there should be no memory issues even if the event is dropped while an instance of it is running. Thanks! - Kristian.