[ 
https://issues.apache.org/jira/browse/DERBY-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Matrigali updated DERBY-3625:
----------------------------------


If this is just a math bug (and not a thread interaction timing issue), then 
the following kind of test should
reproduce but probably takes some playing around to get the row sizes right for 
whatever page size you
pick.  

High level:
create a 2 page table.  On first page vary the amount of free space by 1 byte 
every loop through the
test.  On the second page have a single row that will be moved by compress 
table for each try.

details - here's one way to loop and test all the cases of filling a page, 
there are probably more elegant ways, or you could play around with a test 
looking in toString() from page to find exactly the interesting
lengths of rows:
pick some row size that you are going to move, let's say 100 bytes (this could 
also be variable for even
more exaustive test).  Each loop will drop/create the table (maybe there is a 
way around this).
pick a row something like 2 column with int key and clob data.  1st row 
inserted should exactly
mach the TEST row.  Vary the size of the 2nd row by 
one byte each time, if you load ascii data into the clob then stored size of 
row will go up 1 byte for 
each character.  The idea is to start with the 2nd row big enough such that 
insert of another TEST
row will not fit on the 1st page, and then the varying should inch you up to 
the interesting edge conditions
of completely full page in no reserved space case and full with respect to 
reserved space in other case.

Finally insert 3rd row that should match in length to TEST row.    and commit.  
The goal at this point
is to have a 2 page heap table with 2 rows on page 0 and 1 row on page 1.  

delete 1st TEST row, commit.

run inplace compress.  This should first purge the 1st row in the purge phase, 
and then try to move the
last row on page 1 to page 0.  

updating the space eater row will eat into reserved space which may also be an 
interesting test, but is different than dropping and recreating the table.  



> XSDA3 error in concateTests in lang.LangHarnessJavaTest 
> --------------------------------------------------------
>
>                 Key: DERBY-3625
>                 URL: https://issues.apache.org/jira/browse/DERBY-3625
>             Project: Derby
>          Issue Type: Bug
>          Components: Regression Test Failure
>    Affects Versions: 10.4.1.3
>         Environment: iseries, ibm1.5.:
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
> Classic VM (build 1.5, build JDK-1.5, native threads, jitc_de)
>            Reporter: Myrna van Lunteren
>
> I saw this test fail once with a similar error to DERBY-3180 and DERBY-3381.
> Unfortunately, possibly because it's an old harness test, the db and 
> derby.log were not saved in the 'fail' directory.
> All I have is the stack trace from the output:
> 1) 
> concateTests(org.apache.derbyTesting.functionTests.tests.lang.LangHarnessJavaTest)java.sql.SQLException:
>  Limitation: Record cannot be updated or inserted due to lack of space on the 
> page. Use the parameters derby.storage.pageSize and/or 
> derby.storage.pageReservedSpace to work around this limitation.
>       at java.lang.Throwable.<init>(Throwable.java:196)
>       at java.lang.Exception.<init>(Exception.java:41)
>       at java.sql.SQLException.<init>(SQLException.java:40)
>       at org.apache.derby.impl.jdbc.EmbedSQLException.<init>(Unknown Source)
>       at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
>       at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown 
> Source)
>       at 
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown 
> Source)
>       at 
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown 
> Source)
>       at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown 
> Source)
>       at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown 
> Source)
>       at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown 
> Source)
>       at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown 
> Source)
>       at 
> org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(Unknown 
> Source)
>       at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown 
> Source)
>       at 
> org.apache.derbyTesting.junit.CleanDatabaseTestSetup.compressObjects(CleanDatabaseTestSetup.java:267)
>       at 
> org.apache.derbyTesting.junit.CleanDatabaseTestSetup.cleanDatabase(CleanDatabaseTestSetup.java:166)
>       at 
> org.apache.derbyTesting.junit.CleanDatabaseTestSetup.setUp(CleanDatabaseTestSetup.java:109)
>       at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
>       at junit.extensions.TestSetup.run(TestSetup.java:23)
>       at 
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> Caused by: ERROR XSDA3: Limitation: Record cannot be updated or inserted due 
> to lack of space on the page. Use the parameters derby.storage.pageSize 
> and/or derby.storage.pageReservedSpace to work around this limitation.
>       at java.lang.Throwable.<init>(Throwable.java:196)
>       at java.lang.Exception.<init>(Exception.java:41)
>       at org.apache.derby.iapi.error.StandardException.<init>(Unknown Source)
>       at org.apache.derby.iapi.error.StandardException.<init>(Unknown Source)
>       at org.apache.derby.iapi.error.StandardException.newException(Unknown 
> Source)
>       at 
> org.apache.derby.impl.store.raw.data.CopyRowsOperation.writeOptionalDataToBuffer(Unknown
>  Source)
>       at 
> org.apache.derby.impl.store.raw.data.CopyRowsOperation.<init>(Unknown Source)
>       at 
> org.apache.derby.impl.store.raw.data.LoggableActions.actionCopyRows(Unknown 
> Source)
>       at org.apache.derby.impl.store.raw.data.BasePage.copyInto(Unknown 
> Source)
>       at org.apache.derby.impl.store.raw.data.BasePage.copyAndPurge(Unknown 
> Source)
>       at 
> org.apache.derby.impl.store.raw.data.StoredPage.moveRecordForCompressAtSlot(Unknown
>  Source)
>       at 
> org.apache.derby.impl.store.access.heap.HeapCompressScan.fetchRowsForCompress(Unknown
>  Source)
>       at 
> org.apache.derby.impl.store.access.heap.HeapCompressScan.fetchNextGroup(Unknown
>  Source)
>       at org.apache.derby.iapi.db.OnlineCompress.defragmentRows(Unknown 
> Source)
>       at org.apache.derby.iapi.db.OnlineCompress.compressTable(Unknown Source)
>       at 
> org.apache.derby.catalog.SystemProcedures.SYSCS_INPLACE_COMPRESS_TABLE(Unknown
>  Source)
>       at 
> org.apache.derby.exe.ac4388a4aax0119x3203xfc8fx0000783ef2472.g0(Unknown 
> Source)
>       at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>       at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>       at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown 
> Source)
>       at 
> org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source)
>       at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source)
>       ... 24 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to