[
http://issues.apache.org/jira/browse/DERBY-606?page=comments#action_12455046 ]
Suresh Thalamati commented on DERBY-606:
----------------------------------------
Thanks for considering my suggestions. Extra check(if( !(this instanceof
CompressSpacePageOperation10_2) ) in the CompressSpacePageOperation.java
is ok. You need some kind of check in to correctly call the
writeExternal/readExternal. Only othe alternative I can think of is to
check for formatId instead of using the "instanceof".
While reviewing the latest patches(derby606_impl-v4.diff and
derby606_upgrade-v4.diff ),
noticed you are disabling IN_PLACE_COMPRESS on soft-upgrade to 10.3, in my
view that is incorrect. If I understand correctly this bug happens only on
large data size and does not leave the database in the corrupt state.
I believe right thing to do is to use the old log record on soft-upgrade to
10.3 and allow compress. If you would like to be real nice to the users
then you can catch the bugs case and throw an error message, but I think it is
not required; users hitting the bug case first time on a a soft-upgrade is
almost zero probability.
Index:
java/engine/org/apache/derby/impl/store/raw/data/LoggableAllocActions.java
+ if(
t.getLogFactory().checkVersion(RawStoreFactory.DERBY_STORE_MAJOR_VERSION_10,
+
RawStoreFactory.DERBY_STORE_MINOR_VERSION_3,
+ "CompressSpace operation on an existing
database") )
Above call throws an exception if version is not at the correct level, in this
case if not at 10.3. I think if you pass "null" for feature name , it will
just return true/false.
Please also fix the upgrade tests also, if you decide to allow compress on
soft-upgrade.
I am sorry for missing this in my previous review.
There is one major problem with the latest patch, it can make database
non-recoverable on upgrade from 10.2.
1) Formatid are incorrect for CompressSpacePageOperation10_2 and
CompressSpacePageOperation.
CompressSpacePageOperation should have the new format id and the
CompressSpacePageOperation10_2 should have the OLD one.
Related changes :
Index:
java/engine/org/apache/derby/impl/store/raw/data/CompressSpacePageOperation10_2.java
+
+ /**
+ Return my format identifier.
+ */
+ public int getTypeFormatId() {
+ return super.getTypeFormatId();
+ }
I am sure , you wanted it to return StoredFormatIds.LOGOP_COMPRESS10_2_SPACE;
and also :
Index: java/engine/org/apache/derby/iapi/services/io/RegisteredFormatIds.java
+ /* 465 */
"org.apache.derby.impl.store.raw.data.CompressSpacePageOperation10_2",
That shoud have been
"org.apache.derby.impl.store.raw.data.CompressSpacePageOperation" and you
should change existing entry for compress to "CompressSpacePageOperation10_2".
and the format id numbers should get changed also :
Index: java/engine/org/apache/derby/iapi/services/io/StoredFormatIds.java
public static final int LOGOP_COMPRESS_SPACE =
(MIN_ID_2 + 454);
+ /* org.apache.derby.impl.store.raw.data.CompressSpacePageOperation10_2
*/
+ public static final int LOGOP_COMPRESS10_2_SPACE =
+ (MIN_ID_2 + 465);
+
2) In the upgrade test , why you need to insert 104000 rows ? I think you
can produce the compress log record with less number of records and reduce
the test time.
+ try {
+ checkDataToCase606(conn, 0, 104000, true);
+ } catch(SQLException sqle) {
+ passed = isExpectedException(sqle, "XSLB1");
+ }
Thanks
-suresh
> 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
> Fix For: 10.3.0.0
>
> Attachments: A606Test.java, derby606-v2.diff, derby606-v3.diff,
> derby606_impl-v4.diff, derby606_upgrade-v4.diff, derby606_v1.diff
>
>
> 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
