[
https://issues.apache.org/jira/browse/DERBY-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-5679:
---------------------------------
Attachment: derby-5679-01-ab-storedPageChange.diff
Attaching derby-5679-01-ab-storedPageChange.diff. This second approach changes
update code in StoredPage. I am not an expert in this area and am not confident
that this is the correct fix. The patch, however, does satisfy three useful
conditions:
1) It makes the repro run correctly.
2) It doesn't break any of our existing regression tests.
3) It is small.
Let me explain what I did.
I started out being suspicious of the first update in the repro, the one whose
comment suggested that it was making a crucial change which set up the bug:
--This update is important.
UPDATE TABLE1 SET STR2 = 'before2';
I noticed that the value for one of the other columns became correct after the
rollback if the "important" update was followed by another update which
explicitly set the other new column to null:
-- this fixes the problem
update TABLE1 set str1 = null;
This suggested that the bug could at least be patched over by forcing the other
new columns to be null during the "important" update.
Tracing through the code, I noticed that during the "important" update, the
untouched columns took an unusual trajectory through the StoredPage.logRow()
pinball machine. There they fell into this code block at line 3970. The block
appears to have puzzled other people:
// this is an update that is increasing the number of
// columns but not providing any value, strange ...
spaceAvailable =
logColumn(
null, 0, out, spaceAvailable,
columnFlag, overflowThreshold);
I fixed this case by inventing a new column flag to tell StoredPage.logColumn()
that it should write a null column, rather than a nonexistent one.
Would appreciate your thoughts about this approach.
Touches the following files:
------------
M java/engine/org/apache/derby/impl/store/raw/data/StoredPage.java
The fix.
------------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/AlterTableTest.java
Regression test case.
> Rolling back a transaction leads to an inconsistent state
> ---------------------------------------------------------
>
> Key: DERBY-5679
> URL: https://issues.apache.org/jira/browse/DERBY-5679
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.6.2.1, 10.8.2.2
> Environment: >sysinfo
> ------------------ Java Information ------------------
> Java Version: 1.6.0_26
> Java Vendor: Sun Microsystems Inc.
> Java home: C:\Program Files (x86)\Java\jre6
> Java classpath: .;C:\Program Files
> (x86)\Java\jre7\lib\ext\QTJava.zip;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derby.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbynet.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbyclient.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbytools.jar
> OS name: Windows 7
> OS architecture: x86
> OS version: 6.1
> Java user name: bmason
> Java user home: C:\Users\BMASON
> Java user dir: C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> java.runtime.version: 1.6.0_26-b03
> --------- Derby Information --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derby.jar] 10.8.2.2 -
> (1181258)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbytools.jar]
> 10.8.2.2 - (1181258)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbynet.jar]
> 10.8.2.2 - (1181258)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbyclient.jar]
> 10.8.2.2 - (1181258)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> Current Locale : [English/New Zealand [en_NZ]]
> Found support for locale: [cs]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [de_DE]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [es]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [fr]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [hu]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [it]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [ja_JP]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [ko_KR]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [pl]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [pt_BR]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [ru]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [zh_CN]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [zh_TW]
> version: 10.8.2.2 - (1181258)
> ------------------------------------------------------
> Reporter: Brett Mason
> Priority: Critical
> Attachments: RollbackFails - expected output.txt, RollbackFails.sql,
> derby-5679-01-aa-alterTableTouchAllRows.diff,
> derby-5679-01-ab-storedPageChange.diff
>
>
> Rolling back a transaction can leave a table in an inconsistent state if the
> table has been previously altered through the addition of new columns. It
> appears that if newly added columns have not been changed from their default
> value, then when a transaction which sets new values for these columns is
> rolled back the new columns are not restored to their previous values.
> Attached is an ij script with fairly minimal steps to reproduce the problem
> on Derby 10.6.2.0 and 10.8.2.2 (Win7 x64, Sun 32-bit JRE 1.6.0.26). Expected
> and observed output also attached.
> Would appreciate any suggestions as to a workaround for this issue. Running
> SYSCS_UTIL.SYSCS_COMPRESS_TABLE on the table after adding the columns seems
> to avoid the problem but may be just masking the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
