On Sun, May 10, 2020 at 8:26 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Denis Kovalchuk wrote on Sat, 09 May 2020 23:37 +0300: ... > > Regarding the problem with verification depending on the guarantees > > provided by SQLite: If we cannot rely on SQLite guarantees, then I > > think we should not rely on the guarantee that the table does not > > change when it is read using one statement (which the current > > implementation relies on). In other words we should either rely on all > > SQLite guarantees or not rely on any. > > I don't see things quite the same way as you. > > For starters, while I'm not familiar with SQLite's implementation, > I expect that an implementation that locks out writers entirely will be > less susceptible to bugs than one that permits concurrent writes. In > other words, the assumption that «verify» in trunk makes is presumably > less likely to be violated than the assumption that the patch would have > it make. ... > > Speaking about other approaches, such as sharding rep-cache.db: It may be a > > good approach, but I think there may and probably will be other associated > > problems that are currently unknown. > > You have just committed FUD.
>From the peanut gallery: I don't see this as FUD. Not unless we also consider your statement about SQLite's potential lesser guarantees FUD, if we would implement Denis' solution. In reality anything we do carries a bit of risk. Whether the risk is greater by leaning on more SQLite guarantees, or rolling our own solution, is not clear to me. FWIW, I do consider it an improvement if 'verify' would not hinder commits. We should consider the different possible approaches, of course, without exclusion / prejudice. Just another peanut: perhaps we could make the non-write-blocking-verify-behaviour optional? That is: if we have (even a theoretical) worry that it might lessen the guarantees of verify, let the admin decide? --allow-concurrent-writes or something (just an idea). -- Johan
