Still finding it with the 172 jar. Here is the complete stack trace: Exception in thread "main" java.lang.RuntimeException: org.h2.jdbc.JdbcSQLException: General error: "java.lang.RuntimeException: old!=record pos:540 old:page[540] b-tree leaf table:713 entries:0 new:page[540] data leaf table:16 T_TBL1 entries:4 parent:521 keys:[1115, 1116, 1117, 1118, 0] offsets:[2043, 2038, 2033, 2028, 0]"; SQL statement: INSERT INTO t_tbl1 (age) values (188) [50000-172] at com.code42.tools.H2CorruptionTest.doWork(H2CorruptionTest.java:56) at com.code42.tools.H2CorruptionTest.main(H2CorruptionTest.java:200) Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.lang.RuntimeException: old!=record pos:540 old:page[540] b-tree leaf table:713 entries:0 new:page[540] data leaf table:16 T_TBL1 entries:4 parent:521 keys:[1115, 1116, 1117, 1118, 0] offsets:[2043, 2038, 2033, 2028, 0]"; SQL statement: INSERT INTO t_tbl1 (age) values (188) [50000-172] at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) at org.h2.message.DbException.get(DbException.java:158) at org.h2.message.DbException.convert(DbException.java:281) at org.h2.table.RegularTable.addRow(RegularTable.java:142) at org.h2.command.dml.Insert.insertRows(Insert.java:126) at org.h2.command.dml.Insert.update(Insert.java:86) at org.h2.command.CommandContainer.update(CommandContainer.java:79) at org.h2.command.Command.executeUpdate(Command.java:235) at org.h2.jdbc.JdbcPreparedStatement.execute(JdbcPreparedStatement.java:193) at com.code42.tools.H2CorruptionTest.executeSQL(H2CorruptionTest.java:195) at com.code42.tools.H2CorruptionTest.doInsert(H2CorruptionTest.java:113) at com.code42.tools.H2CorruptionTest.doWork(H2CorruptionTest.java:50) ... 1 more Caused by: java.lang.RuntimeException: old!=record pos:540 old:page[540] b-tree leaf table:713 entries:0 new:page[540] data leaf table:16 T_TBL1 entries:4 parent:521 keys:[1115, 1116, 1117, 1118, 0] offsets:[2043, 2038, 2033, 2028, 0] at org.h2.message.DbException.throwInternalError(DbException.java:228) at org.h2.util.CacheLRU.update(CacheLRU.java:124) at org.h2.store.PageStore.update(PageStore.java:1062) at org.h2.index.PageDataLeaf.addRowTry(PageDataLeaf.java:207) at org.h2.index.PageDataLeaf.split(PageDataLeaf.java:373) at org.h2.index.PageDataNode.addRowTry(PageDataNode.java:138) at org.h2.index.PageDataIndex.addTry(PageDataIndex.java:172) at org.h2.index.PageDataIndex.add(PageDataIndex.java:135) at org.h2.table.RegularTable.addRow(RegularTable.java:124) ... 9 more
On Monday, June 10, 2013 3:12:57 PM UTC-5, Andrew Helgeson wrote: > > Hello Thomas, > > I'm encountering a consistent H2 corruption problem. From my testing, I > believe it involves the caching of select distinct query results. I am > seeing corruption occur consistently when a table reaches > MAX_MEMORY_ROWS_DISTINCT (default 10k) and a select distinct with inner > join is done on the table. Changing the value of this setting reliably > changes the corruption point. > > Attached is the smallest reproducible test case I could create. The > MAX_MEMORY_ROWS_DISTINCT can be set below 500 but due to timing it may not > corrupt. Albeit nonsensical, the join on the second table in conjunction > with the select distinct appears a necessary factor in reproducing the bug. > The corruption always occurs after the maximum number of rows exceeds > MAX_MEMORY_ROWS_DISTINCT. > > The corruption has been encountered on versions 1.3.163/170/172 of H2. > Once the database has reached this state it cannot be dumped. > > Thanks > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
