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

[hyc@symas.com]

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/