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 Thu, 16 Nov 2006 16:01:39 GMT
    [ http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12450437 ] 
            
Mayuresh Nirhali commented on DERBY-606:
----------------------------------------

Thanks Suresh for your comments.

I got a little further with the additional Class approach and as you mentioned I had to create
another child of CompressSpacePageOperation that will behave just like the original one was
until now. But, The new class will still use the typeFormatId of the base class.
I also added another method in RawTransaction that returns LogFactory and with this the DB
versio checks are made in LoggableAllocActions, thanks for this suggestion. I hope this will
be useful in the future as well. The assertion is still kept, but modified to handle -1 value.

having said that, I will be glad to consider any other approach than creating these child
classes. But, the approach of doing db versions checks in read/write methods, I believe, isnt
a good option.

I shall move onto extending OnlineCompressTest to cover this case.
I am currently running derbyall with my patch and shall attach it soon.


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