lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-1474) Incorrect SegmentInfo.delCount when IndexReader.flush() is used
Date Thu, 21 May 2009 09:32:45 GMT


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:
>             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:
> 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 call will fail with an error when assertions are enabled.
> java.lang.AssertionError: delete count mismatch: info=3 vs BitVector=2
> 	at org.apache.lucene.index.SegmentReader.loadDeletedDocs(
> [...]

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:
For additional commands, e-mail:

View raw message