db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6797) If a (machine/jvm) crash happens during hard upgrade, derby does not roll back the upgrade.
Date Wed, 04 Mar 2015 18:34:38 GMT

     [ 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

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:,
>            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

View raw message