[ 
https://issues.apache.org/jira/browse/DERBY-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden updated DERBY-4181:
----------------------------------

    Attachment: ReproDerby4181.out
                ReproDerby4181.derby.log
                ReproDerby4181.java

Attached is a smaller reproduction with just a single thread calling the tests 
DbUtil.add_one_row method in a loop and checking tables after each insert. 
Unfortunately this still has some randomness but fails quickly, sometimes after 
as few as 5 rows.
I tried just inserting one row, using values that I saw fail from the 
derby.log, but could not pop it that way.

Note: this  is not a multi-threaded problem. The reason we always had a problem 
at 36XXX was because our setup had 6 insert threads doing 6000 inserts each and 
we never did any kind of integrity checking until the first delete after the 
setup was complete.

I will continue to try to narrow it down and remove the randomness, but thought 
I would post what I had so far.



> SQLState.LANG_IGNORE_MISSING_INDEX_ROW_DURING_DELETE during NsTest run 
> -----------------------------------------------------------------------
>
>                 Key: DERBY-4181
>                 URL: https://issues.apache.org/jira/browse/DERBY-4181
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.4.2.0, 10.5.1.0, 10.5.1.1, 10.6.0.0
>         Environment: Suse Linux 10, IBM 1.6 SR4
>            Reporter: Myrna van Lunteren
>         Attachments: log_excerpt_sample_assert.txt, ReproDerby4181.derby.log, 
> ReproDerby4181.java, ReproDerby4181.out, run1serverlog.jar, serverlog.jar
>
>
> During the NsTest runs for 10.5.1.0 and 10.5.1.1 I initially ignored warnings 
> showing up in the server's derby.log file:
> WARNING: While deleting a row from a table the index row for base table row 
> (594,12) was not found in index with conglomerate id 1,185.  This problem has 
> automatically been corrected as part of the delete operation.
> However, I don't think this is a completely healthy warning, I think it 
> indicates there was corruption in the index.
> I'll investigate further.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to