Insert-during-iterate deadlock

[dbbnrl]

In my application I sometimes generate DB entries from existing entries. The pattern is that I iterate over a range of existing keys, occasionally creating new entries (outside the iterator range) as I go.

It looks like Fjall is deadlocking in this scenario after some number of insertions. I thought perhaps using the snapshot feature would help, but it makes no difference.

Glancing at the code, I can see that create_iter takes a bunch of Read locks which it holds until the iterator is dropped. Presumably the insert code is attempting to grab a Write lock at some point (memtable flush?) so this isn't a surprising outcome...

I thought about reporting this as an issue but if this kind of usage is an explicit non-goal of Fjall I didn't want to do that.

Is this supported? Supportable?

[marvin-j97]

Hmm yeah this is a bit of a conundrum.

Presumably the insert code is attempting to grab a Write lock at some point (memtable flush?)

Yeah, this is correct. I think using try_lock may fix this, but as a consequence memory usage may grow past its intended limits because all the write buffer checks need to be skipped. Insert (lsm-tree is working as intended) itself is not deadlocking, but the write buffer stuff that comes after is.

[marvin-j97]

Writing to a batch should work though... (a transaction would also work)

let mut batch = keyspace.batch();

let iter = db.snapshot().iter();

for kv in iter {
  batch.insert(&db, k, v);
}

batch.commit()?;

[dbbnrl]

That does seem to work, thanks!

[marvin-j97]

I will track this in #74

I think there are some things that can be improved