* [PATCH 13/13] V2Writeable.pm: In unindex_oid delete the message from msgmap
2018-08-01 16:41 5% [PATCH 00/13]: Incremental index fixes Eric W. Biederman
@ 2018-08-01 16:43 7% ` Eric W. Biederman
0 siblings, 0 replies; 2+ results
From: Eric W. Biederman @ 2018-08-01 16:43 UTC (permalink / raw)
To: Eric Wong; +Cc: meta, Eric W. Biederman
Now that we track the num highwater mark it is safe to remove messages
from msgmap that have been previously allocated. Removing even the
highest numbered article will no longer cause new message numbers to
move backwards.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
lib/PublicInbox/V2Writable.pm | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/PublicInbox/V2Writable.pm b/lib/PublicInbox/V2Writable.pm
index 4dd14331a78f..0396d9f58e55 100644
--- a/lib/PublicInbox/V2Writable.pm
+++ b/lib/PublicInbox/V2Writable.pm
@@ -842,7 +842,10 @@ sub unindex_oid {
warn "BUG: multiple articles linked to $oid\n",
join(',',sort keys %gone), "\n";
}
- $self->{unindexed}->{$_}++ foreach keys %gone;
+ foreach my $num (keys %gone) {
+ $self->{unindexed}->{$_}++;
+ $self->{mm}->num_delete($num);
+ }
$self->unindex_oid_remote($oid, $mid);
}
}
--
2.17.1
^ permalink raw reply related [relevance 7%]
* [PATCH 00/13]: Incremental index fixes
@ 2018-08-01 16:41 5% Eric W. Biederman
2018-08-01 16:43 7% ` [PATCH 13/13] V2Writeable.pm: In unindex_oid delete the message from msgmap Eric W. Biederman
0 siblings, 1 reply; 2+ results
From: Eric W. Biederman @ 2018-08-01 16:41 UTC (permalink / raw)
To: Eric Wong; +Cc: meta
Eric,
Recently I noticed some weird indexing on one of my mailboxes. So I dug
in and made the index_sync tests more robust and found several corner
cases where the current code can be problematic. What follows are the
test cases and fixes for those cases.
The big one is when a message with the highest message number is
deleted. This can cause message numbers to be reassigned so I
explicitly track the highest message number assigned.
Very confusing when reading mail there is a case in SearchIdx
that has been assigning message numbers in the wrong order. Depending
on your time range that can be very confusing as old messages show up
before newer ones.
Finally in v2 deleted messages have not been being deleted from the
msgmap. Which while great for keeping message numbers from going
backwards it means things still show up that shouldn't.
Eric W. Biederman (13):
Import.pm: Don't assume {in} and {out} always exist
t/v1reindex.t: Isolate the test cases
t/v2reindex.t: Isolate the test cases more
t/v[12]reindex.t: Place expected second in Xapian tests
t/v[12]reindex.t: Test that the resulting msgmap is as expected
t/v[12]reindex.t: Test incremental indexing works
SearchIdx.pm: Always assign numbers backwards during incremental indexing
Msgmap.pm: Track the largest value of num ever assigned
t/v[12]reindex.t Verify num_highwater
t/v[12]reindex.t: Verify the num highwater is as expected
SearchIdx,V2Writeable: Update num_highwater on optimized deletes
V2Writeable.pm: Ensure that a found message number is in the msgmap
V2Writeable.pm: In unindex_oid delete the message from msgmap
lib/PublicInbox/Import.pm | 1 +
lib/PublicInbox/Msgmap.pm | 23 ++-
lib/PublicInbox/SearchIdx.pm | 30 ++--
lib/PublicInbox/V2Writable.pm | 20 ++-
t/v1reindex.t | 359 ++++++++++++++++++++++++++++++++++++------
t/v2reindex.t | 335 +++++++++++++++++++++++++++++++++++----
6 files changed, 666 insertions(+), 102 deletions(-)
Eric
^ permalink raw reply [relevance 5%]
Results 1-2 of 2 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2018-08-01 16:41 5% [PATCH 00/13]: Incremental index fixes Eric W. Biederman
2018-08-01 16:43 7% ` [PATCH 13/13] V2Writeable.pm: In unindex_oid delete the message from msgmap Eric W. Biederman
Code repositories for project(s) associated with this public inbox
https://80x24.org/public-inbox.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).