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.