db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3099) Possible bug in interaction with buffer manager causing pages not to be freed on rollback to savepoint
Date Wed, 03 Oct 2007 13:24:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532096
] 

Knut Anders Hatlen commented on DERBY-3099:
-------------------------------------------

To disable the scan for free entries in a buffer manager which is not full, make this change
to Clock.findFreeItem():

@@ -860,7 +860,7 @@
 
 		// no need to sync on getting the sizes since if they are
 		// wrong we will discover it in the loop.
-		if (validItemCount < holders.size()) {
+		if (false&&validItemCount < holders.size()) {
 
 			synchronized (this) {
 

Below is a dump of the alloc page at the same point in the test when running with the scan
disabled. Major differences:

  a) page 2 is not free
  b) 6th byte (status byte) is zero, whereas the only valid values are 1 (valid) and 2 (invalid).
However, the pageStatus flag is 1.
  c) firstFreeByte, freeSpace and totalSpace are different

*** 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: valid, in use 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, 1191416310107)) Overflow: false PageVersion: 27 SlotsInUse: 0
DeletedRowCount: 0 PageStatus: 1 NextId: 6 firstFreeByte: 109 freeSpace: 3979 totalSpace:
3979 spareSpace: 0 PageSize: 4096
---------------------------------------------------
Hex dump:
00000000: 0076 0000 0000 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  ................
.
.
.

> 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.


Mime
View raw message