Johan Corveleyn wrote on Sun, 10 May 2020 21:39 +0200:
> 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,
I will reply to this part offlist. I shall leave it to Johan to bring
back conclusions of the offlist discussion to the list, should and
insofar as he may choose to do so. In the meantime, let's get the
thread back on topic. I look to hearing Denis's concerns with the
sharding approach.
> 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).
In general, we should push decisions onto administrators when they
involve tradeoffs wherein we are ill-place to make a choice.
In this case, the tradeoff would seem to be among:
- ship 1.14's «verify» and require «build-repcache» to be run afterwards;
- ship the «verify» in the OP, about whose correctness we are less
certain, but which doesn't require running «build-repcache» afterwards;
- ship some other solution.
Firstly, we can research the correctness of the patch in the OP's
approach: that is something we are _better_ placed to research than
admins. Secondly, we should brainstorm what other approaches may be
possible, and consider the ones that have already been proposed.
I'll not post any further to this thread for a few days.
Daniel
P.S. When I say "the ones", the plural is correct. The sharding
solution isn't the only alternative on the table.
Received on 2020-05-11 14:09:51 CEST