The vacuuming integration tests set VacuumInterval to a very high
number to avoid vacuuming collisions. This is done after the cluster
is healthy, so Samba will have already been started and vacuuming will
already be scheduled *at the default interval* for databases attached
by Samba. This means that vacuuming controls used by vacuuming tests
can still collide with the scheduled vacuuming events.
Add some logic to reschedule a vacuuming event that has fired but
where VacuumInterval has increased since it was originally scheduled.
The increase in VacuumInterval is used as the time offset for
rescheduling the event.
Although this changes production behaviour for the convenience of
testing, the new behaviour is completely reasonable and obeys the
principle of least surprise.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Tue Apr 7 03:04:57 UTC 2020 on sn-devel-184
bool full_vacuum_run = false;
int ret;
+ if (vacuum_interval > vacuum_handle->vacuum_interval) {
+ uint32_t d = vacuum_interval - vacuum_handle->vacuum_interval;
+
+ DBG_INFO("Vacuum interval increased from "
+ "%"PRIu32" to %"PRIu32", rescheduling\n",
+ vacuum_handle->vacuum_interval,
+ vacuum_interval);
+ vacuum_handle->vacuum_interval = vacuum_interval;
+ tevent_add_timer(ctdb->ev,
+ vacuum_handle,
+ timeval_current_ofs(d, 0),
+ ctdb_vacuum_event,
+ vacuum_handle);
+ return;
+ }
+
vacuum_handle->vacuum_interval = vacuum_interval;
if (vacuum_handle->fast_path_count >= fast_path_max) {