Mike Matrigali created DERBY-5738:
-------------------------------------
Summary: SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE only returns to
the OS pages in the last extent
Key: DERBY-5738
URL: https://issues.apache.org/jira/browse/DERBY-5738
Project: Derby
Issue Type: Bug
Affects Versions: 10.8.2.2, 10.7.1.1, 10.6.2.1, 10.5.3.0, 10.4.2.0,
10.3.3.0, 10.2.2.0, 10.1.3.1
Reporter: Mike Matrigali
It looks like inplace compress only gives back space to the OS from the empty
pages in the last extent of the file. If the defrag and purge phases are
run they can reclaim internal space in the form of free pages to be used for
future inserts, but free pages before last extent are not returned to
OS.
Only current workaround is to use SYSCS_UTIL.SYSCS_COMPRESS_TABLE instead.
In filecontainer.java!compressContainer there is a comment with steps to be
performed, but no code exists for step 5 and 6:
This is outline of the algorithm used in compressing the container.
Until a non free page is found loop, in each loop return to the OS
all space at the end of the container occupied by free pages, including
the allocation page itself if all of it's pages are free.
1) Find last 2 allocation pages in container (last if there is only one).
2) invalidate the allocation information cached by the container.
Without the cache no page can be gotten from the container. Pages
already in the page cache are not affected. Thus by latching the
allocPage and invalidating the allocation cache, this NTT blocks out
all page gets from this container until it commits.
3) the allocPage determines which pages can be released to the OS,
mark that in its data structure (the alloc extent). Mark the
contiguous block of nallocated/free pages at the end of the file
as unallocated. This change is associated with the NTT.
4) The NTT calls the OS to deallocate the space from the file. Note
that the system can handle being booted and asked to get an allocated
page which is past end of file, it just extends the file automatically.
5) If freeing all space on the alloc page, and there is more than one
alloc page, then free the alloc page - this requires an update to the
previous alloc page which the loop has kept latched also.
6) if the last alloc page was deleted, restart loop at #1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
