[
https://issues.apache.org/jira/browse/DERBY-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744438#action_12744438
]
Knut Anders Hatlen commented on DERBY-4081:
-------------------------------------------
Thanks for the reminder, Rick.
I think I've found a way to expose this problem now. Just continuously
executing "insert into t(x) values 0" followed by "delete from t", where T.X is
unique nullable and with auto-commit off, consistently hangs on the 372nd
iteration.
On 10.5.1.1 that repro fails with a WaitError (DERBY-4097). It does not expose
the problem on 10.4.2.0 or earlier since DERBY-4028 hides the problem by
stopping the check for duplicates too early.
> BTreeController.comparePreviousRecord() may fail to release latch on
> left-most leaf
> -----------------------------------------------------------------------------------
>
> Key: DERBY-4081
> URL: https://issues.apache.org/jira/browse/DERBY-4081
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.4.2.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Attachments: derby-4081-1a.diff
>
>
> If comparePreviousRecord() is called on some other leaf page than the
> left-most leaf, and all the rows to the left of the current position are
> deleted so that the position is moved all the way to slot 0 on the left-most
> leaf, comparePreviousRecord() will return without releasing the latch on the
> left-most leaf. Only the leaf on which comparePreviousRecord() is called
> should be latched when the method returns.
> Since comparePreviousRecord() currently fails to continue after finding a
> deleted row, this bug is not possible to expose until DERBY-4028 is fixed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
