[ http://issues.apache.org/jira/browse/DERBY-1248?page=all ]
Mike Matrigali updated DERBY-1248: ---------------------------------- After looking at the test5.zip, I believe I understand what is going on. The original database has a single log file file: log1.dat. It's last record is (1,285606), while in the backup the last log record is (1,279540). So the "missing" log records are all in the last block of the log file. I think the problem is that the online backup reads page "through" the cache, rather than from disk so it is picking up "dirty" pages where the associated log records have not yet been flushed to disk. The backup of the log file on the other hand goes directly from disk and thus sometimes in this concurrent test misses some of the log records in the unflushed part of the log file. In this test most of the "concurrent" work is actually post commit committed delete cleanup which happens to use "no-sync" commit, thus the only flushes coming are either from filling a block or from the backup itself. I believe the fix is easy, just have the backup flush the log file after it has backed up all the data, and before backing up the remaining log files at the end. I spent some time trying to get a more reproducible case but haven't gotten anywhere there. It makes sense that it is more likely on multiprocessors where the backup and other threads can be running at same time. > Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql > ----------------------------------------------------------------------------- > > Key: DERBY-1248 > URL: http://issues.apache.org/jira/browse/DERBY-1248 > Project: Derby > Type: Bug > Components: Store, Regression Test Failure > Versions: 10.2.0.0 > Environment: Sun JVM 1.5.0_04 on Solaris 10 x86. Derby from trunk (revision > 396285). Sane build. > Reporter: Knut Anders Hatlen > Attachments: derby_335.log, linuxfailure.zip, solaris-singlecpu.zip, > solarisfailure.zip, storemore.zip, test2_379.jar, test335.jar, test5.zip > > I saw this error when I ran derbyall. > ********* Diff file derbyall/storeall/storemore/onlineBackupTest4.diff > *** Start: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 > 11:51:50 *** > 68 del > < ij(CONNECTION1)> select * from ctest; > 69 del > < ID |NAME > > 70 del > < > -------------------------------------------------------------------------------------------------------------------------------------------- > 71 del > < 1 |derby backup/compress test > & > 72 del > < 2 |derby backup/compress test > & > 73 del > < 300 |derby backup/compress test > & > 74 del > < 509 |derby backup/compress test > & > 75 del > < 510 |derby backup/compress test > & > 76 del > < 511 |derby backup/compress test > & > 77 del > < 512 |derby backup/compress test > & > 78 del > < ij(CONNECTION1)> insert into ctest values(2000, 'restore was successfil') ; > 79 del > < 1 row inserted/updated/deleted > 80 del > < ij(CONNECTION1)> > 80 add > > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED shiftUp > > failed, low must be between 0 and recordCount. low = 140, recordCount = 2 > > ERROR XJ040: Failed to start database 'wombat', see the next exception for > > details. > > ERROR XJ001: Java exception: 'ASSERT FAILED shiftUp failed, low must be > > between 0 and recordCount. low = 140, recordCount = 2: > > org.apache.derby.shared.common.sanity.AssertFailure'. > > ij> select * from ctest; > > IJ ERROR: Unable to establish connection > > ij> insert into ctest values(2000, 'restore was successfil') ; > > IJ ERROR: Unable to establish connection > > ij> > Test Failed. > *** End: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 > 11:51:56 *** > The test usually succeeds, but I managed to reproduce the failure by running > this loop in the shell: > touch onlineBackupTest4.pass > while [ -f onlineBackupTest4.pass ]; do > rm onlineBackupTest4.pass > java org.apache.derbyTesting.functionTests.harness.RunTest > store/onlineBackupTest4.sql > done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
