For Samba 4.10, the behaviour of the paged results control (1.2.840.113522.214.171.1249, RFC2696) has been changed to more closely match Windows servers, to improve memory usage. Paged results may be used internally (or is requested by the user) by LDAP libraries or tools that deal with large result sizes, for example, when listing all the objects in the database.
Previously, results were returned as a snapshot of the database but now, some changes made to the set of results while paging may be reflected in the responses. If strict inter-record consistency is required in answers (which is not possible on Windows with large result sets), consider avoiding the paged results control or alternatively, it might be possible to enforce restrictions using the LDAP filter expression.
RFC2696 does not specify how an implementation should behave in the case of simultaneous modification. Before Samba 4.10, results were temporarily saved in memory and were fed back the client as required.
Real world example
Although the consistency has been changed, realistically most clients will not see any impact. Paged results normally cause a stream of requests to happen in rapid succession, leaving little time to modify the database in between. Besides full searches, attributes of interest should not be changed all that frequently to begin with.
There are not that many ways to correlate data across the directory by default, and maintaining this data is quite difficult because of the lack of transactions over LDAP and the requirement for clients to perform constrained LDAP modification consistently in every case.
External race conditions
Without using LDAP constrained modifications to ensure no one else has changed a particular value, it is quite easy to introduce a race condition.