This was a regression caused by db15fcfa899e1fe4d6994f68ceb299921b8aa6f1 for empty lists.
The original code never dereferenced attrs and only added "*" if attrs was NULL (not if attrs was NULL).
This causes significant performance issues with the new paged_results module introduced for 4.10 as the initial GUID search requests no attributes. This GUID search turns into a search for "*" and ends up allocating memory for the entire database.
This never appears to cause changes in the final result set, only intermediate processing.
Created attachment 14927 [details]
Patch for master
After testing again, this actually did cause changes to the final result set.
Specifically, connecting via LDAP and connecting via the local database returns different answers. With this patch, the two now both return no attributes. We probably need some tests to make sure that this behaviour isn't accidentally broken again.
Right now triggering remote LDAP searches via LDB turns empty lists into searches for all attributes (as the LDAP specification dictates) because no mapping occurs.
In order to align the answers from the local database and the remote we need to change the ildap module to translate empty lists into searches for the OID "1.1" as described in RFC 2251, Section 4.5.1: 'If the client does not want any attributes returned, it can specify a list containing only the attribute with OID "1.1".
For anyone who actually wants all the attributes, they can either use "*" or fail to supply an attribute list.
Bug filed separately for LDB discrepancies:
Created attachment 15024 [details]
improvement in timing
Created attachment 15025 [details]
improvement in absolute timing
Created attachment 15026 [details]
performance improvement json
Created attachment 15027 [details]
Backported patch for 4.10
Please select this performance regression fix for 4.10.
(In reply to Andrew Bartlett from comment #10)
Pushed to autobuild-v4-10-test.
(In reply to Karolin Seeger from comment #11)
Pushed to v4-10-test.
Closing out bug report.