[
https://issues.apache.org/jira/browse/DERBY-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-2549:
----------------------------------
notes on the recent patch:
o it looks like your new lines expect 8 space tabs, derby code should either
use not indent tabs or should use
4 space tabs.
o this level of code should not be doing -- on the page number, it should use
the raw store interfaces to move
to next and previous pages. There are a couple of reasons:
1) even though the current raw store implementation dones have pages for
each container laid out from 0 to N,
future implementations may not.
2) The get next and get previous interfaces take care of postioning on
the next USER head page -- by doing
-- or ++ you may get put on an overflow row page, a raw store
internal bit map page, ...
o As you found in your debugging the problem with my previous patch was that
the position of the scan was not
properly maintained in the scan_position (that will teach me to copy/paste
code from other parts of system).
I think a better fix would be to properly position the scan on the right
row, rather than letting the code get to
the postion at next page code path and then reposition backward to the
previous page.
Scan positions are meant to be maintained by a couple of different means.
While you have a latch on the page
it is fine to just maintain the slot number as nothing can change out from
under you unless you do it. If you
are going to give up the latch on heap scan then the usual way to maintain
a scan is by getting the record
handl associated with the current slot number, then this can be used to
repostion the scan the next trip back.
I'll post another patch with a suggestion, let me know what you think.
Again I haven't had time to debug it.
Also it would be good to get a test added to the test suite for this bug,
do you plan on doing that? I think the
easiest case would be:
o create a table with 1 column, smallest datatype possible - say smallint,
and largest page size. It would be good if the
test case had more than 200 rows that could be moved so it would test
visiting the same page more than
2 times.
o add enough rows to get a reasonable number of pages - say 10.
o delete rows leaving at least one row per page, probably easiest if you
just delete every row execept each 100th row in the order you inserted them ,
or something like that.
> ArrayIndexOutOfBoundsException in SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE
> -------------------------------------------------------------------------
>
> Key: DERBY-2549
> URL: https://issues.apache.org/jira/browse/DERBY-2549
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.2.2.0
> Environment: Linux 2.6.x, JRE 1.5.0_b7
> Reporter: Kurt Huwig
> Assigned To: Mayuresh Nirhali
> Attachments: 2549-histogram.png, A2549Test.java, derby-2549-v1.diff,
> derby2549_mikem.diff, derby2549_v2.diff, DerbyDiskSpaceDiag.java
>
>
> I am doing this in my code:
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('SPONTS','" +
> "journal".toUpperCase(Locale.US) + "',1,1,1)")
> ("journal" is actually a String-variable, but I replaced it here for easier
> understanding)
> Sometime - not always - I am getting this exception:
> java.sql.SQLException: The exception
> 'java.lang.ArrayIndexOutOfBoundsException: 100' was thrown while evaluating
> an expression. SQLSTATE: XJ001:
> Java exception: '100: java.lang.ArrayIndexOutOfBoundsException'.
> at
> org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.Statement.execute(Unknown Source)
> [...]
> Caused by: org.apache.derby.client.am.SqlException: The exception
> 'java.lang.ArrayIndexOutOfBoundsException: 100' was thrown while evaluating
> an expression.
> SQLSTATE: XJ001: Java exception: '100:
> java.lang.ArrayIndexOutOfBoundsException'.
> at org.apache.derby.client.am.Statement.completeExecute(Unknown
> Source)
> at
> org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown
> Source)
> at
> org.apache.derby.client.net.NetStatementReply.readExecuteCall(Unknown Source)
> at org.apache.derby.client.net.StatementReply.readExecuteCall(Unknown
> Source)
> at org.apache.derby.client.net.NetStatement.readExecuteCall_(Unknown
> Source)
> at org.apache.derby.client.am.Statement.readExecuteCall(Unknown
> Source)
> at org.apache.derby.client.am.Statement.flowExecute(Unknown Source)
> at org.apache.derby.client.am.Statement.executeX(Unknown Source)
> ... 12 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
