[ https://issues.apache.org/jira/browse/DERBY-5738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-5738: ---------------------------------- Component/s: Store > 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 > Components: Store > Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, > 10.6.2.1, 10.7.1.1, 10.8.2.2 > 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 For more information on JIRA, see: http://www.atlassian.com/software/jira