db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mayuresh Nirhali (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-606) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables
Date Tue, 14 Nov 2006 15:20:39 GMT
    [ 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

        

Mime
View raw message