[ 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.
|