On Wed, Jan 8, 2020 at 7:50 AM Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
wrote:
> Nathan Hartman <hartman.nathan_at_gmail.com> writes:
>
> > SVN-4588 "Item index too large in revision" is marked as Unresolved, but
> > from my reading of all the comments, it seems the root cause of the
> problem
> > was not restarting httpd after dumping and loading, leaving stale
> > information in cache.
> >
> > The last comment mentions a similar report on Stack Overflow. That one
> > magically fixed itself by rebooting. See:
> >
> https://stackoverflow.com/questions/33904618/how-to-increase-l2p-page-size/33938501
> >
> > So... is there anything else to do for this one?
>
> There is an option of making the filesystem instance IDs part of the cache
> keys. Doing so would fix the case described in SVN-4588 and allow other
> operations that happen through the command-line tools, such as "svnadmin
> hotcopy" to work properly without the server restart.
>
> See
> https://lists.apache.org/thread.html/6db0186496a46c9823a752b377e369eb4361c8a42e62fc7e601453c6%401440460036%40%3Cdev.subversion.apache.org%3E
My reading of the above left me confused. On one hand, it sounds like that
should greatly reduce the probability of this problem. OTOH it seems like
some people had concerns: Apparently not including the instance ID in the
cache keys helps to "fail early"?
So my questions:
1. Are there any downsides to doing it?
2. Since it reduces, but does not completely eliminate, the probability of
this issue, are there any additional steps we could take? For example is it
possible to detect a running svnserve/httpd and warn about it?
Thanks,
Nathan
<https://lists.apache.org/thread.html/6db0186496a46c9823a752b377e369eb4361c8a42e62fc7e601453c6%401440460036%40%3Cdev.subversion.apache.org%3E>
Received on 2020-01-09 13:29:16 CET