Howard Chu writes:

h.b.furuseth@usit.uio.no wrote:

...

Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if and only if rs.sr_entry->e_private != NULL. Which is possibly true with back-bdb but seems a shaky assumption in general.)

That is a requirement, yes. If you implement a backend that has cache/locking constraints on its entries and you don't provide a pointer from the entry back to your cache state, then you're an idiot.

OTOH you can send an entry without setting MUSTRELEASE, and release it after sending instead. In particular if you didn't about the undocumented sr_flags and their purpose. Or if you don't use be_release for unlocking but just to clean up e_private.

... have I gone blind? I don't see back-bdb setting that flag. Did I just read ITS#3671 and trust it to have updated bdb?