https://bugs.openldap.org/show_bug.cgi?id=8958

--- Comment #26 from Howard Chu hyc@openldap.org --- (In reply to Howard Chu from comment #25)

(In reply to Hallvard Furuseth from comment #17)

...

Duuh, right. I got stuck looking for what's special about the indexing task and couldn't find it:-( I need to make it special.

So, let tasks declare their expected speed until finish or between pausechecks. At FAST=1 (default) and SLOW=0. A pause only stops tasks with speed < ltp_pause. In thread_pool_pause(), replace the WANT_PAUSE stage with

while (++ltp_pause <= max speed) { wait until no more tasks with speed < ltp_pause; }

Then fast tasks should breeze past slow ones when preparing to pause. Until all threads have slow tasks, anyway.

I don't understand how this solves anything. If a slow indexing task is currently running, and a fast config mod comes in, it's still the case that the config change could pull the DB out from under the indexer task. So there's nothing safe about letting the fast task progress while the slow task is still running.

I don't think we should be changing anything else about how tpool handles pauses. We should just be fixing this specific case of the indexer being a slow task, by implementing checkpointing into the indexer. I.e., when it detects a pause request it should save its current progress and pause itself. If it gets resumed it can pick up where it left off, or if a config change affects it it can abort or or start over. A checkpointing mechanism is needed anyway, for the case of a (clean) shutdown while the indexer is running.