-
Jens Even Berg Blomsøy authored
Problem: During an I_S upgrade, we re-evaluate dependent views, e.g. 'sys.schema_auto_increment_columns', which depends on more than one I_S table. While re-creating the first I_S view, none of the other ones referred by the sys scheme view are created yet; hence the sys schema view is considered invalid, and thus, we get an error message in the error log since at this point, the error handler hook is set to my_message_stderr(). Currently when error_handler_hook is set to my_message_stderr, the view state is updated as "invalid" but error message logging is not skipped or suppressed. Eventually, the I_S views are all created, meaning that the sys schema view is set as valid. The same issue and errors is present for P_S upgrades. As in the tables does not yet exist, and are then reported as ER_NO_SUCH_TABLE, but they will exist when upgrade is finished. So the main issue here is the error messages that create a bit of noise in the error log. Solution: Update View_metadata_updater_error_handler to convert all errors except DEADLOCK, TIMEOUT or STACK_OVERFLOW errors to ER_VIEW_INVALID while updating views metadata. To be used in open_views_and_update_metadata(). Change-Id: Ic7092a63cd3d23ace0bb83bb9d125a917b660ce0
Jens Even Berg Blomsøy authoredProblem: During an I_S upgrade, we re-evaluate dependent views, e.g. 'sys.schema_auto_increment_columns', which depends on more than one I_S table. While re-creating the first I_S view, none of the other ones referred by the sys scheme view are created yet; hence the sys schema view is considered invalid, and thus, we get an error message in the error log since at this point, the error handler hook is set to my_message_stderr(). Currently when error_handler_hook is set to my_message_stderr, the view state is updated as "invalid" but error message logging is not skipped or suppressed. Eventually, the I_S views are all created, meaning that the sys schema view is set as valid. The same issue and errors is present for P_S upgrades. As in the tables does not yet exist, and are then reported as ER_NO_SUCH_TABLE, but they will exist when upgrade is finished. So the main issue here is the error messages that create a bit of noise in the error log. Solution: Update View_metadata_updater_error_handler to convert all errors except DEADLOCK, TIMEOUT or STACK_OVERFLOW errors to ER_VIEW_INVALID while updating views metadata. To be used in open_views_and_update_metadata(). Change-Id: Ic7092a63cd3d23ace0bb83bb9d125a917b660ce0
Loading