Daniel Shahaf wrote on Sat, 28 Mar 2020 21:54 +0000:
> Stefan Sperling wrote on Sat, 28 Mar 2020 11:32 +0100:
> > On Fri, Mar 27, 2020 at 10:58:48PM +0000, Daniel Shahaf wrote:
> > > Well, I guess the documentation, once written, should point out that if
> > > any single revision build-repcache operates on adds a large number of
> > > reps, commits made in parallel to the build-repcache run will be starved
> > > out of adding their own rep-cache entries, which will manifest as
> > > "post-commit FS processing failed". (We have a bug filed for this, but
> > > I can't find its number right now, sorry.)
> >
> > Good point.
> >
> > Maybe the command's help output should mention that the repository will
> > be blocked for commits while this command is running? Even if that isn't
> > entirely true at the implementation level it would be good user-facing
> > advice.
>
> I don't think inaccuracies in the documentation are a good idea. The
> proposal might discourage people from running this when they could;
> might lead people to run this in order to trigger the side effect of
> blocking commits for a short while, only to find commits did happen
> successfully; and might get people to distrust our documentation in
> general.
>
> Therefore, I'd document the semantics accurately. If need be, we can
> refer to fuller documentation in the release notes and/or the book.
By the way, couldn't we just fix this, rather than document it?
Looking at write_reps_to_cache(), it won't be that hard to rewrite it
to INSERT into rep-cache in batches of N reps per SQLite transaction,
rather than one SQLite transaction per commit. This'll fix the bug
I mentioned.
Makes sense?
Denis, would you like to look into this? It looks like an easy,
localized fix, and your build-repcache patch will benefit from it, too.
Cheers,
Daniel
Received on 2020-03-28 23:07:08 CET