From f3952d947b08f4d29c5899852a98cf465a105ad5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Kuzn=C3=ADk?= Date: Fri, 1 May 2020 09:03:46 +0100 Subject: [PATCH] ITS#9059 Document why we do FIND_CSN --- servers/slapd/overlays/syncprov.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 3c14796cd2..b99f3e22d3 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -2882,7 +2882,18 @@ no_change: if ( !(op->o_sync_mode & SLAP_SYNC_PERSIST) ) { ldap_pvt_thread_mutex_unlock( &sl->sl_mutex ); } } - /* Is the CSN still present in the database? */ + /* + * If sessionlog wasn't useful, see if we can find at least one entry + * that hasn't changed based on the cookie. + * + * TODO: Using mincsn only (rather than the whole cookie) will + * under-approximate the set of entries that haven't changed, but we + * can't look up CSNs by serverid with the current indexing support. + * + * As a result, dormant serverids in the cluster become mincsns and + * more likely to make syncprov_findcsn(,FIND_CSN,) fail -> triggering + * an expensive refresh... + */ if ( !do_present ) { gotstate = 1; } else if ( syncprov_findcsn( op, FIND_CSN, &mincsn ) != LDAP_SUCCESS ) {