2 ms·
I'd be interested to read some discussion on why this wasn't caught earlier. When you have some thing with supports read + write and supports access from multip
by mort96 4y ago
I'd be interested to read some discussion on why this wasn't caught earlier. When you have some thing with supports read + write and supports access from multiple threads/processes, I'd expect "read as fast as possible from one thread, write as fast as possible from another" to be one of the most obvious tests to write.
- loeg 4y agoSeems like it was particularly the lock upgrade path in the memdb vfs — so a little weird case that must have not been covered adequately. https://www.sqlite.org/src/info/15f0be8a640e7bfa https://www.sqlite.org/src/info/15f0be8a640e7bfa
- deleted 4y ago[deleted]
- morelisp 4y agoI vaguely recall some variant of MC/DC coverage that also treats each bit in any bit flag checks as independent boolean conditions. It seems like there could be a similar variant that requires checking each value of such a "leveled" enum independently; if your enum says you can take on values 0-5 and the logic checks <= 2 and <= 5, nonetheless there should be a test case for 0, 1, 3, and 4.
- YetAnotherNick 4y agoAlso this is not even a silent bug, so I would have expected that this would have been caught by someone in production.
- xk3 4y agoI've experienced this a few times before but I just ignored it because I never had access issues after waiting for the other process to finish writing. I wonder what the patch will really do, is it just a better error message or will SQLITE show only committed data?