CURRENT branch

Julien ÉLIE julien at
Sun May 10 20:20:12 UTC 2009

Hi Jeff,

>> Okay, that's disturbing.  Yeah, it sounds like we broke out-of-order
>> overview storage somehow.  I suspect Jeff's patch since we're getting
>> the diagnostic message that he added.
>> I'm not sure I could have made this test case harder to understand if I
>> tried.  :)


> I definitely don't understand what's going on, sadly!

I have added the length of the mapped DAT file:

Invalid or inaccessible entry for article 4 in ov-tmp/e/t/example.test1.IDX: offset 299 length 256 datalength 299
Invalid or inaccessible entry for article 2 in ov-tmp/e/t/example.test3.IDX: offset 165 length 256 datalength 165
Invalid or inaccessible entry for article 3 in ov-tmp/e/t/example.test1.IDX: offset 555 length 250 datalength 299

The test suite does:


The problem comes from the last three entries.
As example.test1 already has article #5, the DAT file is not remapped
when article #4 comes (article #4 is at offset 299).
The same thing happens for example.test3 and again example.test1
(article #3 is at offset 299+256=555).

When we run tdx_search_open(), the remap is now done only when the high
water mark becomes superior to the mapped high water mark.
Here, high water mark = 4 is not superior to the mapped high water mark = 5.
Therefore, tdx_search() does not see it and ends up with that error.

It is what happens.
The articles would be seen by tdx_search() if the DAT file was remapped
by tdx_search_open(), but we have to change the logic which triggers that:

    if (end > data->high && high > data->high) {
        data->high = high;

Maybe a boolean in the group_data structure to say whether the file should
be remapped?  (The boolean would be set during tdx_data_add().)

Any better idea?

Julien ÉLIE

« Les propositions mathématiques sont reçues comme vraies
  parce que personne n'a intérêt qu'elles soient fausses. » (Montesquieu) 

More information about the inn-workers mailing list