Hallvard Breien Furuseth wrote: > On 1/19/19 8:04 PM, Howard Chu wrote: >> modifications to cn=3Dconfig require no other threads to be active. On= ce the background indexer >> starts running, its activity will of course block further cn=3Dconfig = modifications until it >> completes. >=20 > Nothing "of course" about it.=C2=A0 I don't know why running > the background indexer is considered a change to cn=3Dconfig.
It is not. But the indexing rules can be changed by further config mods, = and we don't want the config to change out from under it. > The ldapmodify did the change to cn=3Dconfig and completed. >=20 > I can guess that it might block cn=3Dconfig simply because that's > the safe way to have both an indexer and dynamic config.=C2=A0 Or > I can read the code.=C2=A0 But "read the code" !=3D "of course". This was all discussed on the -devel mailing list when the feature was fi= rst implemented. http://www.openldap.org/lists/openldap-devel/200504/msg00090.html > So... back to start, I guess I was suggesting that the > indexing task should stop if another config mod comes in, > if it can resume afterwards.=C2=A0 And the config change need > only fail if it might prevent the indexer from resuming. > I suppose that gets complicated in a hurry though. Stopping and resuming is problematic, especially if other config changes = to the DB occur that would invalidate the in-progress indexing. We could arrange to return LDAP_BUSY to config mods if any background ind= exers are running. Or as I already mentioned, we could try to only do this for relevant conf= ig mods, e.g. to the active backend, or to global schema. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
