henrik.bohnenk...@ionos.com wrote: > On Thu, Jun 27, 2019 at 10:34:19PM -0700, Quanah Gibson-Mount wrote: >> --On Sunday, April 07, 2019 10:15 AM +0000 henrik.bohnenk...@ionos.com >> wrote: >> >>> On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote: >> >> Had a customer who was hitting this issue try out these patches -- It >> greatly decreases the search time (from unknown/infinite to 1 minute). >> Unfortunately slapd then segv's. Working on getting a test database to >> reproduce the issue with for a good backtrace. > > oh, that's too bad. I'd be happy to participate in the bug hunt. May I > ask: which version did your customer use? I have modified the patch to > work with the recent changes on master, but I did not dig in very deep > to understand these changes. So I must admit that these modifications > to the patch are completely untested (except the tests in the tests > subdir). > > Things might work better with the 2.4.46/47 patch, if that is an > option for your customer. > > Wrt getting a test-tree, maybe the python script I have in the github > repo for the patch can provide > one. > (https://github.com/hbo/openldap-mdb-deref-problem/blob/master/scripts/write_tree.py) > > I'm of course very interested to keep this patch alive, so if you have > details on the segv, please let me know.
Fyi, on our problematic test database with 11M entries and 3.7M aliases, a search with -a always , starting from the DB suffix, took 4 minutes without this patch, and 1235 minutes with this patch. Needless to say, that's not looking good. Still checking other test cases. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
