Stan wrote:

>
> is there any known workaround?
> is this a known issue?
> or should I file it in the tracker?
>

Sorry, the answer to all of those is "I don't know" - I'm
hoping for someone to jump in here, but this is a four day
weekend for most Europeans, so the answer may not be immediate.

The original error is in the code that handles the page cache.
Careful write is maintained by keeping track of interpage
dependencies, and writing out each page before pages that
depend on it - where "depend" means that they reference it.
For example, if you need to fragment a record, you write the
tail first, then the beginning of the record that points to
the page that contains the tail. Sometimes those relationships
can become circular - page 403 contains a fragmented record
with the tail on page 501 and page 501 contains a fragmented
record with the tail on page 403. At that point, each page
needs to be written before the other, and nothing good will
happen. In theory, the check_precedence routine notices
those problems before they occur (before the record on 503
gets fragmented and placed on 403) and writes out the higher
precedence pages before making a change. This time that
check failed - the page was changed before the cycle was
broken.

But how or why that happened, I can't say.


Regards,


Ann