RATIONALE Fix so that restore does not fail if there are events, triggers enabled on the restore server. To fix BUG#36530. SUMMARY When restoring events and triggers, these objects should not be active before the restore process completes. Note that restore operation is not on-line and all tables being restored are locked. Also, data might be inconsistent during the restore and become consistent only when the restore is completed. Thus events and triggers which are created together with other meta-data should not fire during the restore process. DELIVERABLE: Changes to the backup kernel which ensure that triggers and events do not fire during the restore process but only when it is complete, i.e., all other objects and all table data are restored.
PROPOSED SOLUTION: Change backup kernel so that events and triggers are created *after* all table data has been restored. Thus the events and triggers to be restored will not exist in the server when table data is restored. Note: According to the analysis done for WL#4211 it is correct to recreate triggers and events at the end as no other object can depend on them. To be on the safe side, one should first create triggers and then events. Serialization data for events and triggers is read before the table data. However, we can materialize a server object from its serialization string without actually creating it in the server. Object can be created later using execute() method. Thus events and triggers should be only materialized during metadata reading phase and executed after table data restore is completed.
It is enough to make these changes in the backup kernel code: 1. In function bcat_create_item(): do not execute a materialized object if it is a trigger or event. 2. In Backup_restore_ctx::do_restore() method: at the end, after a call to restore_table_data(), iterate over all triggers and then all events and execute them.