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/