On Sun, May 10, 2020 at 8:26 PM Daniel Shahaf <d.s_at_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
Received on 2020-05-10 21:39:53 CEST