This bug is created as a clone of upstream ticket:
Turning an older email thread into a ticket:
in cl5_api we have a semaphore which a comment says is used to limit the number of concurrent writes, the default value is: 2
But. The semaphore is only used
- in writing an update to the changelog in write_changelog_and_ruv(), which is serialized by the backend lock and so there always will only be one
- in log_ruv_elements (when changelog is reloaded).
- ldif import
It is NOT used in changelog trimming, purging of cleaned RIDs, changelog compaction.
so, in the cases where we do use it there will be no more than two parallel updates, in cases wheer there is, or could be, heavy update contention like changelog trimming while updates are applied iz is not used.
I think it was possibly useful when writing the changelog was a real postop, so the semaphore played the role of the backend lock.
So far I only have seen problems reported about the semaphore file when it could not be deleted, recreated and I don't see any benefit in keeping it.
Replication acceptance tests passed, marking as VERIFIED, SanityOnly.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.