On 22.01.2019 19:55, OndÅej KuznÃk wrote: > The problem is not that it's still scheduled when the pause is > requested, scheduled tasks don't prevent a pause (and I think some > of them need to be a bit more aware of that fact), but that it's been > picked up by a worker thread and is running while cn=config waits for > them to pause.
_And_ that a pause request is all-or-nothing. This demo code of graduated wait-for-pause works for me. For RE24, it doesn't combine easily with Git master's multiple tpool queues:-( ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190124.patch.gz But I'm not volunteering to write one for master anytime soon, unless someone has less complicated ideas for that than I do. A real version looks like more work than I expected anyway. > What I was suggesting was that it could check every so often whether it > might be holding up a pause and join it just like some other tasks do. > But that's only a good idea if it's able to handle the changes that > happen during the pause (indexes reconfigured again, the database going > away, ...) as well as being able to release any locks temporarily. Yes. I should have answered that, but I still cannot decide what I think of it. I see no locks to worry about in that code, but the rest does make me nervous. Possibly we can find some times where we can pause safely, but not a general case. For example, in the case of back-mdb we could register scheduled config operations the database itself, in a "(TODO)" LMDB DB. Doesn't help with schema changes, but does help renumbering slapd DBs. -- Hallvard
