On Tue, Oct 05, 2021 at 04:39:54AM +, Eric Wong wrote:
> Eric Wong wrote:
> > b) just reindex in place (it /should/ work...)
>
> I reindexing live on yhbt/lore and it didn't break...
>
> Btw, did you see my other questions about whether or not boost
> was in use?
Yes, but I was attending
The leak's been there for a while, but I couldn't find
other reports of it:
https://rt.cpan.org/Public/Bug/Display.html?id=139622
Anybody else want to try this and see which versions of Encode
or Perl hit this leak? Encode is bundled with Perl, but at
least Debian also provides an optional
This lets administrators reindex specific time ranges
according to git "approxidate" formats. These arguments
are passed directly to underlying git-log(1) invocations
and may still reach into old epochs.
Since these options rely on git committer dates (which we infer
from the most recent
`shard_remove_eidx_info' was made unnecessary with commit
82b805db3ad9 (searchidxshard: IPC conversion, part 2, 2021-01-03)
and we now call `remove_eidx_info' directly.
---
lib/PublicInbox/OverIdx.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/PublicInbox/OverIdx.pm
-extindex still needs to support --{since,until,...},
but I got -index working with them, at least.
I initially failed to guard the last*commit SQLite
updates with since/until, and didn't notice it until
I started writing tests.
Eric Wong (3):
extsearchidx: favor 20-byte OID comparison
As with most of our internal-only code, favor smaller
comparisons to reduce memory traffic.
---
lib/PublicInbox/ExtSearchIdx.pm | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/PublicInbox/ExtSearchIdx.pm b/lib/PublicInbox/ExtSearchIdx.pm
index eb7c3d67e072..3a1856c84709
Eric Wong wrote:
> This should prevent some false duplicates. I noticed this
> while implementing "lei mail-diff", and only noticed it when
> I implemented the ContentDigestDbg wrapper for mail-diff.
Btw, I completely forgot -extindex has a --dedupe switch
for dealing with situations like this:
