You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <ji...@apache.org> on 2012/04/23 20:12:34 UTC
[jira] [Updated] (DERBY-5679) Rolling back a transaction leads to
an inconsistent state
[ 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-aa-alterTableTouchAllRows.diff
Attaching derby-5679-01-aa-alterTableTouchAllRows.diff. This patch fixes the bug for new ALTER TABLEs.
There is short-circuiting logic in the language layer as well as the store. If the ALTER TABLE ADD COLUMN statement specifies a non-null default, then at execution time we cook up an update statement to stuff that default into the new column in all rows. We don't do this if the default is null. This patch removes that short-circuiting and makes us touch all of the rows if the default is null.
This won't fix the bug if the ALTER TABLE statement happened before upgrading to the release which contains this fix. To fix the bug in that case, we need to fix the storage layer. If we fix the bug in the storage layer, then we probably don't need this change to the language layer.
I'm happy to take a look at the storage layer. I will start poking around. Would appreciate any pointers about where I should be looking, though.
I'm posting this patch in case the store fix turns out to be too tricky.
Touches the following files:
------------
M java/engine/org/apache/derby/impl/sql/execute/AlterTableConstantAction.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
>
>
> 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