[
https://issues.apache.org/jira/browse/DERBY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532053
]
Knut Anders Hatlen commented on DERBY-3099:
-------------------------------------------
Here is a dump of the alloc page right before the call to addPage() in a
successfull test run (clean trunk). Note that page 3, 4, 5 and 6 are marked as
valid, in use pages. I had expected those pages to be free, since the update
that overflowed to them was rolled back.
*** Alloc page ***
nextAllocPageNumber = -1
nextAllocPageOffset = 0
reserved1 = 0
reserved2 = 0
reserved3 = 0
reserved4 = 0
borrowedSpace = 80
extent = -----------------------------------------------------------------------
-------
Extent map of from page 1 to page 10216
page 1: valid, in use page
page 2: free page
page 3: valid, in use page
page 4: valid, in use page
page 5: valid, in use page
page 6: valid, in use page
page 7: free page
From 7 to 10216 are un-allocated pages
------------------------------------------------------------------------------
---------------------------------------------------
page id Page(0,Container(0, 1191405214574)) Overflow: false PageVersion: 28
SlotsInUse: 0 DeletedRowCount: 0 PageStatus: 1 NextId: 6 firstFreeByte: 189
freeSpace: 3899 totalSpace: 3899 spareSpace: 0 PageSize: 4096
---------------------------------------------------
Hex dump:
00000000: 0076 0000 0001 0000 0000 0000 0000 0000 .v..............
00000010: 0000 0006 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0001 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 ffff ffff ................
00000040: ffff ffff 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 5000 0000 ............P...
00000070: 7400 0000 0000 0010 0000 0000 1400 0000 t...............
00000080: 0c00 0100 0800 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 00dc 7f30 ca00 0000 .........?.0?...
000000c0: 0000 0010 0000 0000 0000 0000 0100 0000 ................
000000d0: 0000 0027 e800 0000 0030 0000 0000 0000 .........0......
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
.
.
.
(the rest of the page is just zeros, except the checksum)
> 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.4.0.0
> Reporter: Knut Anders Hatlen
> Attachments: failfast.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.
