hyc@OpenLDAP.org writes:
slapindex.8 1.28 -> 1.29 Document truncate mode
Please clarify the doc of this. I mean, I had no idea slapindex had a non-truncate mode. Does slapindex by default not delete old indexes, or does is mean something else? When should one _not_ use truncate mode?
Hallvard B Furuseth wrote:
hyc@OpenLDAP.org writes:
slapindex.8 1.28 -> 1.29 Document truncate mode
Please clarify the doc of this. I mean, I had no idea slapindex had a non-truncate mode.
Yeah, how about that... The option was in slapcommon.c since rev 1.1 in 1999, but it wasn't actually in the getopt string or in any usage info. Seems nobody noticed in all this time.
Does slapindex by default not delete old indexes
Right. It only adds new data by default.
or does is mean something else? When should one _not_ use truncate mode?
In BerkeleyDB, you cannot use truncate mode with transactions. So in the default mode (without -q), back-bdb/hdb silently removes the truncate flag. (Perhaps it should print an error and abort instead.)
You probably would not want the truncate mode if you've just added a new index type to an already indexed attribute. E.g., you had index cn eq and you changed it to index cn eq,sub
Howard Chu writes:
Hallvard B Furuseth wrote:
Does slapindex by default not delete old indexes
Right. It only adds new data by default. (...) In BerkeleyDB, you cannot use truncate mode with transactions. So in the default mode (without -q), back-bdb/hdb silently removes the truncate flag. (Perhaps it should print an error and abort instead.)
Then the doc has been misleading all this time - "regenerating" the index sounds like cleaning away any junk too. So I suggest a louder change: Add a non-truncate option too, and warn if neither option is used. And a note in back-bdb(5) that removing (and maybe re-adding) an index with cn=config does not clean away old index data.
Hallvard B Furuseth wrote:
Howard Chu writes:
Hallvard B Furuseth wrote:
Does slapindex by default not delete old indexes
Right. It only adds new data by default. (...) In BerkeleyDB, you cannot use truncate mode with transactions. So in the default mode (without -q), back-bdb/hdb silently removes the truncate flag. (Perhaps it should print an error and abort instead.)
Then the doc has been misleading all this time - "regenerating" the index sounds like cleaning away any junk too. So I suggest a louder change: Add a non-truncate option too, and warn if neither option is used.
That seems unnecessary. Nobody has had a problem with this behavior in 8 years.
And a note in back-bdb(5) that removing (and maybe re-adding) an index with cn=config does not clean away old index data.
That may be warranted. Probably a lot easier than actually sweeping away the old data.
Howard Chu writes:
Hallvard B Furuseth wrote:
Then the doc has been misleading all this time - "regenerating" the index sounds like cleaning away any junk too. So I suggest a louder change: Add a non-truncate option too, and warn if neither option is used.
That seems unnecessary. Nobody has had a problem with this behavior in 8 years.
Well, the problem would normally just be poorer performance or more memory use than necessary.
-
Hallvard B Furuseth -
Howard Chu -
Howard Chu