In London, we introduced the concept of reglomming so that we can alter a logical column that has shared its storage (physical column) with others. The reglomming works by assigning a new physical column with the new desired length/type to the logical column. In the case when there is no such physical column available, an alter will be initialized to alter table and add the physical column.
During upgrade, if a varchar logical column glommed incorrectly to a clob/mediumText physical column, the reglomming code will trigger and this process might require to alter table and add a new physical column.
We have noticed that there are few logical columns on descendant of task table that are incorrectly glommed to CLOB. Hence, additional task alter might be initialized when upgrading to London-patch0 which will add additional hours to the upgrade (worst case scenario ~4.5 hours).
A fix is going into LP1. The fix will skip the table alters and leave the glommed columns in a state such that customers may see fields in weird states. If customers want to fix this they can re-glomm the column which will use a table alter, but this can be done at their discretion and outside of the upgrade.
Steps to Reproduce
1) Find the storage alias for change_request.conflict_status:
Let's assume that the alias is a_str_15
2) Alter the physical column a_str_15 on task table to be a medium text
3) run upgrade or just upgrade plugin="com.snc.maintenance_schedules"
4) Looking at the logs notice that we're reglomming change_request.conflict_status to a varchar physical column
This could happen for any glommed string column that is glommed incorrectly to medium text and there exist a sys_dictionary.xml file for it in the update folder of a plugin.
The unwanted alter is going to be fixed in LP1, so to avoid longer upgrades customer can skip upgrade to LP0 and wait to upgrade to LP1.
Related Problem: PRB1294630