[ https://issues.apache.org/jira/browse/DERBY-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-6797: -------------------------------------- Attachment: Prepare4Upgrade.java HardUpgradeAbort.java AfterUpgrade.java attaching a few classes that could be used to manually test this. Would require to change DD_version in the new version to that it does fail somewhere. The programs are: - Prepare4Upgrade: prepare (run with an older Derby version) - HardUpgradeAbort: upgrade (with the modified newer version) - AfterUpgrade: check (with the old version; if the failed upgrade would be correctly rolled back you should not get a connection (version upgraded).). Note that when using trunk you need to pass the property derby.database.allowPreReleaseUpgrade=true to the program because trunk is always at alpha. > If a (machine/jvm) crash happens during hard upgrade, derby does not roll > back the upgrade. > ------------------------------------------------------------------------------------------- > > Key: DERBY-6797 > URL: https://issues.apache.org/jira/browse/DERBY-6797 > Project: Derby > Issue Type: Bug > Components: Store > Affects Versions: 10.11.1.3, 10.12.0.0 > Reporter: Myrna van Lunteren > Attachments: AfterUpgrade.java, DERBY-6797.diff, > HardUpgradeAbort.java, Prepare4Upgrade.java > > > When a crash happens during hard upgrade of derby, the upgrade -up to that > point - is not rolled back. Depending on where the crash happens this might > leave a broken database behind. > This makes it extra important to create a backup before doing a hard upgrade. > I have not tested this with a soft upgrade. > I will attach a test case which uses the upgrade test suite framework and > uses a call of SanityManager.DEBUG_SET("upgrade_abort") to send a flag, and a > change in impl/sql/catalog/DD_version to listen for this flag. > Thus, it's only a test that would run in a sane environment. > But this test does show that even if we see the error during hard upgrade, > the resulting database appears to be in the newer version. I have manually > tested this with 10.11 (by modifying DD_version in 10.11 to throw the error > regardless of sanity manager or not) and with 10.12 by running my new test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)