Re: (ITS#6406) back-ldif fails test043-delta-syncrepl

[h.b.furuseth@usit.uio.no]

I wrote:
> This often fails (producer and consumer databases differ):
>     SLAPD_DEBUG=0x4105 ./run -b ldif test043-delta-syncrepl
> when configured with --enable-accesslog.

Apparently syncprov sends changes in the order it gets them from an
accesslog search, so it needs accesslog to return change records ordered
by change CSN.  Otherwise the consumer discards changes, complaining:

do_syncrep2: rid=001 CSN too old, ignoring 20091130202958.564835Z#000000#000#000000

This works with hdb/bdb under normal operation:  They return entries
ordered by entry ID, which always increases as new entries are added.
It works out since something (syncrepl or accesslog) serializes writes
so change records are added to the log database in the same order as
the changes are applied to the main database.

With back-ndb, I imagine somthing like an SQL 'ORDER BY <reqStart or
entryCSN>' will do the trick, if it isn't already handled.

back-ldif does not support this: It returns changes memcmp-ordered
by normalized reqStart.  Normalization "<t>.210000Z" -> "<t>.21Z"
makes that value sort after "<t>.219999Z".


Anyway, if I have understood this correctly, this requirement needs to
be documented, and it looks rather fragile anyway.  Only databases
supporing this use of accesslog.  The admin must not slapcat the
accesslog, rearrange it (maybe he's looking for changes to something
specific), and then slapadd it back.  Not something which would happen
every day, but there's no reason people _wouldn't_ do it either.  LDAP
defines elements as unordered, after all.

What happens if a consumer does a full refresh from a provider without
accesslog, and is also running syncprov with accesslog?  Do these
changes end up in the consumer accesslog?  I don't suppose the refresh
can send entries by entryCSN order, since there may be children that
were changed before parents.

-- 
Hallvard