Re: test008-concurrency coredump (ITS#2866)

[jongchoi@OpenLDAP.org]

> The most obvious problem here is that the dupbv occurs outside of the
> critical section in slap_get_commit_csn. This means another thread can come
> along in slap_graduate_commit_csn and free the selected csn before dupbv can
> execute, and that is most likely the cause of this particular crash.

This has been already fixed by Howard. Thanks.

> A secondary issue is why slap_get_commit_csn returns the last committed CSN
> in the list, instead of the first. The CSNs are appended to the list in
> order, so later ones in the list will be higher in sequence. But due to
> transaction retries, commits can happen in an arbitrary sequence. This
> approach means the max_csn stored in the database may be greater than any
> actually committed changes. A syncrepl client that updates with this value
> will have missed some transactions (that haven't been committed yet) and
> store this high value in its internal state. Next time it queries it will ask
> for transactions newer than this, so it will never pick up the missed
> transactions.

csne for uncommitted transactions (including those that retries)
has SLAP_CSN_PENDING state. This function returns the last
committed CSN in the list which precedes any csne that is 
in SLAP_CSN_PENDING state (hence uncommitted yet).

- Jong