db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: 10.8.2 coming even closer
Date Thu, 08 Sep 2011 18:03:56 GMT
On 08.09.11 19:22, Myrna van Lunteren wrote:
> Hi,
>
> I will probably not do much work preparing for the release on Friday
> or over the weekend, but still intend to build a release on Monday,
> Sept 12, so checking now on the various things I think are going on
> that might make it:
>
> https://issues.apache.org/jira/browse/DERBY-4275 (Knut):
> 	On Sep 1, Knut wrote: "I think [backport] should be safe. I'll have a
> look. I'll probably resolve the issue again now, since the original
> fix did improve the situation, and file a new report for the remaining
> issue revealed by the regression test case."
> 	It looks like a fix was commited on Sep 2 for the issue revealed by
> the test case - so this issue is now complete and can be closed?
>
> https://issues.apache.org/jira/browse/DERBY-5236 (Knut): On Sep 1,
> Knut wrote "I'm not sure if a complete fix will be in place for 10.8.2
> (or if the complete fix will be suitable for backport since it may
> involve protocol changes), but I intend to backport as much as
> possible of the code in this issue."
>      current status: the following commits went into trunk: 1104365,
> 1163131, 1164495, and a patch is ready for review. No backports to
> 10.8 yet.
>      I'm still hoping this will make it into 10.8, but won't wait the
> release for it.
>
> https://issues.apache.org/jira/browse/DERBY-5347 (Kathey): Still
> working on this, I think.
>
> https://issues.apache.org/jira/browse/DERBY-5363 (Dag): not happening
> for 10.8, looks like. (patch ready for review, gathering info from
> user list).
>
> https://issues.apache.org/jira/browse/DERBY-5398 (Rick submitted a
> patch for review, would be good to get it in).
>
> https://issues.apache.org/jira/browse/DERBY-5404 (Kim): fix was
> committed to trunk (being backported?)
>
> Please let me know of any additions, corrections...

Hi Myrna,

I'm having trouble with DERBY-5367 [1].
When trying to implement the simplest possible fix, by replacing one 
store call with another, I get errors in some of the tests - more 
specifically during transaction rollback. I have one more idea for a fix 
to try out, but I fear the associated performance implications may be 
too severe. I'll try figure that out today, worst case tomorrow.

I believe the bug is a data corruption bug, since the wrong field value 
is stored in the index. To hit it, you have to use a collation, insert 
value A, delete value A, and then insert value A' before the deleted row 
has been reclaimed. The point here is that values A and A' are 
considered equal by the collation, although the string values are 
different. Derby currently updates the row location, but fails to update 
the field value stored in the index.

The simplest example is case insensitive collations (or strengths), as 
was the case in DERBY-5367, where 'Test' and 'test' are considered 
equal. If 'Test' was inserted first, a select query using the index 
would incorrectly return 'Test' whereas a select query not using the 
index would return the correct value 'test'.

If anyone believe they have enough time to produce a working fix before 
Monday, or to figure out what I'm doing wrong, feel free to assign 
yourself to the issue.


Regards,
-- 
Kristian

[1] https://issues.apache.org/jira/browse/DERBY-5367

 >
> Thx,
> Myrna


Mime
View raw message