Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index

[h.b.furuseth@usit.uio.no]

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