[ http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12449683 ] Mayuresh Nirhali commented on DERBY-606: ----------------------------------------
Thanks mike for looking into this and also for the valuable suggestions. They were really helpful to put me in the right direction while I am working on this fix. and sorry, I could not write sooner. I realized that changing CompressedNumber to write negative values will not be appropriate, after looking at the bit patterns. That is for 2 reasons. 1, Need for hard upgrade and 2, the only possible negative value written by CompressedNumber is newHighestPage. So, It is not worth the effort of making it write negative values. Since this is a special case which is true only for CompressSpaceOperation, I was wondering if this can be handled by write/readExternal methods of CompressSpaceOperation itself. When log record is written for this case, a positive value is passed to the log and when it is read back, it is identified to be the correct value. Choosing this positive value would be very critical, I was thinking of Integer.MAX_VALUE. Please let me know if there are any sideaffects of this approach. This can be considered for handling the soft upgrade mode case as well. I am also looking into your suggestions. Is it accepted to change the Log format of record only for one particular operation by not compressing the numbers or did you mean to not compress the numbers for all the operations ?? I can extend the upgradetests based on the approach we agree upon. although, I havent had a chance to look at those tests yet. I would appreciate any more comments on this. Thanks. > SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables > -------------------------------------------------------------------- > > Key: DERBY-606 > URL: http://issues.apache.org/jira/browse/DERBY-606 > Project: Derby > Issue Type: Bug > Components: Store > Affects Versions: 10.1.1.0 > Environment: Java 1.5.0_04 on Windows Server 2003 Web Edition > Reporter: Jeffrey Aguilera > Assigned To: Mayuresh Nirhali > Attachments: A606Test.java > > > SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails with one of the following error > messages when applied to a very large table (>2GB): > Log operation null encounters error writing itself out to the log stream, > this could be caused by an errant log operation or internal log buffer full > due to excessively large log operation. SQLSTATE: XJ001: Java exception: ': > java.io.IOException'. > or > The exception 'java.lang.ArrayIndexOutOfBoundsException' was thrown while > evaluating an expression. SQLSTATE: XJ001: Java exception: ': > java.lang.ArrayIndexOutOfBoundsException'. > In either case, no entry is written to the console log or to derby.log. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
