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:-(
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
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.