[Xapian-tickets] [Xapian] #645: Read block errors after reopen()

[Xapian]

#645: Read block errors after reopen()
---------------------------+-----------------------------
 Reporter:  medoc          |             Owner:  olly
     Type:  defect         |            Status:  assigned
 Priority:  low            |         Milestone:  1.3.3
Component:  Backend-Chert  |           Version:  1.2.16
 Severity:  normal         |        Resolution:
 Keywords:                 |        Blocked By:
 Blocking:                 |  Operating System:  All
---------------------------+-----------------------------
\
\
\
\
Changes (by olly):

 * status:  new => assigned
 * version:   => 1.2.16
 * component:  Other => Backend-Chert
 * milestone:   => 1.3.3

\
\
\

Comment:

 FWIW, a query on a !WritableDatabase can still cause data to be flushed to
 disk, but it's not nearly as brutal as it used to be.

 With the chert backend, if you create an allterms iterator, all pending
 postlist changes are flushed to disk (but not committed).  In query terms,
 that means a wildcard or partial query.

 With the brass backend (at least currently), it will flush (but not
 commit) postlist data for any term used in the query.  The thinking is
 that this means we can just use the standard code to iterate a postlist
 and avoid having special case code for iterating a postlist + pending
 modifications.  For something like recoll with a low query rate and likely
 a small "working set" of terms in a given time window, that should work
 well.

 Brass will also flush all doclength data if you iterate all docs - e.g.
 pure NOT - unless the docids are contiguous (in this special case we
 simply iterates from lowest to highest without reading the actual data
 from disk).

 Brass is also smarter about flushing postlist changes for a wildcard, and
 will only flush the data for terms which match the wildcard (note that
 this data would get flushed when the query was actually run anyway).

 ----

 Anyway, as for the actual issue, this clearly shouldn't happen.  I'll try
 to reproduce it (I do have an SSD, but also a fast CPU).

 I wonder if #640 might be related.
\
\
\

--
Ticket URL: <http://trac.xapian.org/ticket/645#comment:1>
Xapian <http://xapian.org/>
Xapian