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

Thursday, 24 January 2019

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

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006