Re: Troubleshooting threads missing from /all/

Eric Wong wrote: > Konstantin Ryabitsev wrote: > > On Sat, Oct 16, 2021 at 09:43:24AM +, Eric Wong wrote: > > > Eric Wong wrote: > > > > Yes. Though given the current situation with missing messages > > > > from /all/, I'd wait until a reindex recovers the missing > > > > messages (and

[PATCH 2/2] v2: mirrors don't clobber msgs w/ reused Message-IDs

For odd messages with reused Message-IDs, the second message showing up in a mirror (via git-fetch + -index) should never clobber an entry with a different blob in over. This is noticeable only if the messages arrive in-between indexing runs. Fixes: 4441a38481ed ("v2: index forwards (via `git

[PATCH 1/2] extindex: show mismatches for messages deleted from inbox

There seems to be a bug in v2 inbox reindexing somewhere... --- lib/PublicInbox/ExtSearchIdx.pm | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/lib/PublicInbox/ExtSearchIdx.pm b/lib/PublicInbox/ExtSearchIdx.pm index f479cf9e1a3f..4b46fa1622ea 100644 ---

[PATCH 0/2] fix v2 mirrors of reused Message-IDs

Eeep! :< Eric Wong (2): extindex: show mismatches for messages deleted from inbox v2: mirrors don't clobber msgs w/ reused Message-IDs MANIFEST| 1 + lib/PublicInbox/ExtSearchIdx.pm | 14 ++--- lib/PublicInbox/V2Writable.pm | 7 ++-

Re: Troubleshooting threads missing from /all/

Konstantin Ryabitsev wrote: > On Sat, Oct 16, 2021 at 09:43:24AM +, Eric Wong wrote: > > Eric Wong wrote: > > > Yes. Though given the current situation with missing messages > > > from /all/, I'd wait until a reindex recovers the missing > > > messages (and probably a fast fsck checker). >

Re: Troubleshooting threads missing from /all/

On Sat, Oct 16, 2021 at 09:43:24AM +, Eric Wong wrote: > Eric Wong wrote: > > Yes. Though given the current situation with missing messages > > from /all/, I'd wait until a reindex recovers the missing > > messages (and probably a fast fsck checker). > > I think "public-inbox-extindex

[PATCH 2/4] extindex: retry sync_inbox before reindex

Ensure the num highwater mark of the target inbox is stable before using it. Otherwise we may end up repeating work done to index a message. --- lib/PublicInbox/ExtSearchIdx.pm | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/lib/PublicInbox/ExtSearchIdx.pm

[PATCH 4/4] extindex: better locations for {quit} checks

Check for graceful termination at every message since it's a fairly inexpensive check. --- lib/PublicInbox/ExtSearchIdx.pm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/PublicInbox/ExtSearchIdx.pm b/lib/PublicInbox/ExtSearchIdx.pm index cb5256a2c562..f479cf9e1a3f

[PATCH 3/4] extindex: guard against false mismatch unrefs

I'm not sure if this is a bug or not (or it could be an old bug in the v2 indexing code). --- lib/PublicInbox/ExtSearchIdx.pm | 10 ++ 1 file changed, 10 insertions(+) diff --git a/lib/PublicInbox/ExtSearchIdx.pm b/lib/PublicInbox/ExtSearchIdx.pm index daff656d1ac5..cb5256a2c562 100644

[PATCH 0/4] extindex tweaks and small fixes

Probably nothing of note, but some extra safety and redundant work elimination. Eric Wong (4): extindex: use localtime to display lock time extindex: retry sync_inbox before reindex extindex: guard against false mismatch unrefs extindex: better locations for {quit} checks

[PATCH 1/4] extindex: use localtime to display lock time

Since this is intended for use on the command-line, include TZ offset in time and try to shorten the message a bit so it wraps less on a terminal. --- lib/PublicInbox/ExtSearchIdx.pm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/PublicInbox/ExtSearchIdx.pm