[
https://issues.apache.org/jira/browse/LUCENE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711537#action_12711537
]
Michael McCandless commented on LUCENE-1474:
--------------------------------------------
Yes, the damage once done will remain in the index.
This new assert will only trip if the index is recreated, ie when a segment is
first written with the wrong count.
Can you run CheckIndex on your index and report back? I'm curious how many
segments show the wrong delete count, and how much the counts are off.
> Incorrect SegmentInfo.delCount when IndexReader.flush() is used
> ---------------------------------------------------------------
>
> Key: LUCENE-1474
> URL: https://issues.apache.org/jira/browse/LUCENE-1474
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 2.4
> Reporter: Marcel Reutegger
> Assignee: Michael McCandless
> Fix For: 2.4.1, 2.9
>
> Attachments: IndexReaderTest.java
>
>
> When deleted documents are flushed using IndexReader.flush() the delCount in
> SegmentInfo is updated based on the current value and
> SegmentReader.pendingDeleteCount (introduced by LUCENE-1267). It seems that
> pendingDeleteCount is not reset after the commit, which means after a second
> flush() or close() of an index reader the delCount in SegmentInfo is
> incorrect. A subsequent IndexReader.open() call will fail with an error when
> assertions are enabled. E.g.:
> java.lang.AssertionError: delete count mismatch: info=3 vs BitVector=2
> at
> org.apache.lucene.index.SegmentReader.loadDeletedDocs(SegmentReader.java:405)
> [...]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
