couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: Data loss
Date Sat, 07 Aug 2010 22:47:43 GMT
I think you may be right, Damien.
If ever a write happens that only contains conflicts while waiting for
a delayed commit message we might still be cancelling the timer. Is
this what you're thinking? This would be the fix:

On Sat, Aug 7, 2010 at 15:42, Damien Katz <> wrote:
> I think the problem might be that 2 conflicting write attempts in row can leave the #db.waiting_delayed_commit
set but the timer has been cancelled. One that happens, the header may never be written, as
it always thinks a delayed commit will fire soon.
> -Damien
> On Aug 7, 2010, at 12:08 PM, Randall Leeds wrote:
>> On Sat, Aug 7, 2010 at 11:56, Randall Leeds <> wrote:
>>> I agree completely! I immediately thought of this because I wrote that
>>> change. I spent a while staring at it last night but still can't
>>> imagine how it's a problem.
>>> On Sat, Aug 7, 2010 at 11:12, Damien Katz <> wrote:
>>>> SVN commit r954043 looks suspicious. Digging further.
>>>> -Damien
>> I still want to stare at r954043, but it looks to me like there's at
>> least one situation where we do not commit data correctly during
>> compaction. This has to do with the way we now use the path to sync
>> outside the couch_file:process. Check this diff:

View raw message