Previously, the audit_log table was not cleaned correctly, so the FK validation on that table took too long. As a result, the upgrade validation stage also took too long. Now, the audit_log cleanup mechanism has been fixed so that upgrade validation time is normal.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-1119.html
Verified with: rhevm-3.6.6.2-0.1.el6.noarch # \d+ event_notification_hist ... Indexes: "idx_event_notification_hist" btree (audit_log_id) "idx_event_notification_hist_audit_log_id" btree (audit_log_id) Foreign-key constraints: "fk_event_notification_hist_audit_log" FOREIGN KEY (audit_log_id) REFERENCES audit_log(audit_log_id) ON DELETE CASCADE ... # select DeleteAuditLogOlderThenDate('2016-05-05 10:27:38.951+02');