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
                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)

Mime
View raw message