[ https://issues.apache.org/jira/browse/DERBY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-3099: -------------------------------------- Affects Version/s: 10.3.1.4 The bug is also present on the 10.3 branch (I applied the assert.diff patch and got the expected assert failures when I tried to connect to a database). Should the fix be backported, or is it safer just to leave it as it is since there are no known user-visible consequences? > Possible bug in interaction with buffer manager causing pages not to be freed > on rollback to savepoint > ------------------------------------------------------------------------------------------------------ > > Key: DERBY-3099 > URL: https://issues.apache.org/jira/browse/DERBY-3099 > Project: Derby > Issue Type: Bug > Components: Services, Store > Affects Versions: 10.3.1.4, 10.4.0.0 > Reporter: Knut Anders Hatlen > Assignee: Knut Anders Hatlen > Fix For: 10.4.0.0 > > Attachments: assert.diff, d3099-1.diff, failfast.diff, initSpace.diff > > > I noticed this strange behaviour when I was working on DERBY-2911. It seems > like the result of test case P042 in unit/T_RawStoreFactory.unit is dependent > on the actual contents of the buffer manager (which pages have been evicted, > which free entries have been reused and so on). I'm not sure if this is a bug > in the test or somewhere in the code, or if this is expected behaviour, but > it sounds a bit suspicious. > For instance, commenting out all the test cases preceeding P042 makes P042 > fail, even though P042 creates a new container so that it should not be > affected by any of the previous test cases. Also, commenting out a space > optimization in Clock.findFreeItem() so that freed entries are not reused > except when rotateClock() is called on a full cache to find a victim, causes > the test case to fail. A third way to make it fail, is to vary the scan > direction when looking for a free entry to reuse in the new buffer manager > (ConcurrentCache). If the scan is disabled or walks the clock from the > beginning to the end, the test fails, but if the clock is scanned backwards, > it passes. > The code that fails in the test, is > c = t_util.t_openContainer(t, segment, cid, true); > Page checkNextPage = t_util.t_addPage(c); > if (checkNextPage.getPageNumber() == nextPageNumber) > throw T_Fail.testFailMsg( > "expect some pages to be freed by > update rollback"); > The expected page number is 2, and the actual page number is 7. > Before this, a large row has been inserted on page 1 and overflows to page 2, > 3, 4, 5 and 6. Also, page 7 has been added manually before all the updates > were rolled back so that the pages from 2 up to 7 should be unallocated. Page > 7 is then added and removed, and the transaction is committed. After > reopening the container, the test expects the pages from 2 up to 7 to be > free, and that t_addPage() should allocate page number 2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.