Change Record Loading Slowly and Timing Out For Some Users and Not OthersIssue Some users cannot open a change that can be opened by other users. STEPS TO REPRODUCE1. Log in to the instance2. Impersonate USERb3. Navigate to Change > All4. Query by number = CHG12345675. Open change CHG1234567 It never loads and the instance shows these messages after five minutes: Transaction CanceledYour transaction has been canceledTime : 298378 msReason: maximum execution time exceeded The change will not load for USERb but it will load for USERa (fast). Regarding the user that cannot open the change, the log file shows the /change_request.do transaction with lots of lines like the following: Compacting large row block (file.write: sys_audit 10000 rows 160840 saveSize)Compacting large row block (file.write: sys_audit 10000 rows 160000 saveSize)Compacting large row block (file.write: sys_audit 10000 rows 160000 saveSize) and the following line: Query that got us here is: TABLENAME = sys_audit ENCODED_QUERY = documentkey=d41add49db341c54e0c8dc19f4961942^record_checkpoint>-1^sys_created_on>=2020-05-13 22:57:32^sys_created_on<=2020-05-15 15:48:28^ORDERBYrecord_checkpoint and the following lines: WARNING *** WARNING *** GlideOutputWriter@29748899: Large amount of data has been streamed: 143,986,718 bytesWARNING *** WARNING *** GlideOutputWriter@29748899: Large amount of data has been streamed: 145,045,602 bytesWARNING *** WARNING *** GlideOutputWriter@29748899: Large amount of data has been streamed: 146,104,502 bytes2020-05-15 08:33:31 (497) Default-thread-1 365106ADDB305894CAF0DC19F49619F0 txid=d9f4ca6ddbf0 SEVERE *** ERROR *** The transaction cancellation form could not be loaded. ReleaseNew YorkCauseThe user that can open the change is using an existing history set, but the users that cannot open the change does not have a history set and the instance is trying to build up a new history set. A new history set is created for each possible combination of the following user profile factors:-Language-Timezone-Domain-Date/Time Format The problem is that there is too much data in sys_audit for that specific change and the transaction gets canceled before the instance is able to create a new history set. Resolution Workaround is for the user that cannot open the change, to modify his own settings ( timezone/language/date-time format/domain ) so that they match a combination for which the history set already exists. This would allow the user to open the change, since the instance would not try to create a new history set. See KB0784651 for other possible workarounds Related LinksOther workarounds could be found in : KB0784651 - Timeout or excessive load time for record with large sys_audit data for Activity Stream on form Explanation of history sets : KB0744473 - History sets - How are they generated