[ http://issues.apache.org/jira/browse/DERBY-606?page=all ]
Mike Matrigali updated DERBY-606: --------------------------------- o my suggestion was to only change what this log record wrote, not all log records that used compressed number. If you are going to change the format of what is written, then it seems simpler to just write the number uncompressed than to add an extra decoding. Note "change" the format is not really allowed. What you need to do is support the old log record and add a new log record which has the changed format. For soft upgrade you need to always read/write the old log record. For hard upgrade you need to write new format and be able to read both old and new log record, once you have hard upgraded you don't have to worry about older versions of the software encountering this unknown new log record. o note if you choose a fix which in any way alters what is written, I think you basically have to add a new log record in case of hard upgrade (and bug will continue to exist in soft upgrade). You can save copying code by having the new log record extend the existing one and just update the getTypeFormatId(), readExternal(), writeExternal() routines. This way soft upgrade can still read/write the old record. Need some code to write the new vs. the old one in case of hard upgrade. o if you decide you want to look at runtime fix vs. log record fix let me know and maybe I can give some pointers. > 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
