Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 98931 invoked from network); 12 Sep 2006 07:10:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Sep 2006 07:10:50 -0000 Received: (qmail 54560 invoked by uid 500); 12 Sep 2006 07:10:48 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 54534 invoked by uid 500); 12 Sep 2006 07:10:48 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 54525 invoked by uid 99); 12 Sep 2006 07:10:46 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Sep 2006 00:10:46 -0700 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received: from ([209.237.227.198:41541] helo=brutus.apache.org) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id D6/21-00869-28D56054 for ; Tue, 12 Sep 2006 00:10:58 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 4F07B714329 for ; Tue, 12 Sep 2006 07:07:23 +0000 (GMT) Message-ID: <6239308.1158044843320.JavaMail.jira@brutus> Date: Tue, 12 Sep 2006 00:07:23 -0700 (PDT) From: "Suresh Thalamati (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-1786) a crash during re-encryption of an existing database with lot of tables can make database unrecoverable on a next boot. In-Reply-To: <22761195.1156978523546.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1786?page=all ] Suresh Thalamati updated DERBY-1786: ------------------------------------ Attachment: derby-1786.diff The problem was when transaction log spans more than one log file during (re) encryption of the database and if there is a crash just before switching the database to use the new encryption properties; On recovery checkpoint in the first log file is used as reference and the next log file is assumed to have the commit log record for (re) encryption and deleted incorrectly to force the roll-back , which lead to the incomplete rollback of re-encryption. And that caused recovery failures on next (re) encryption crashed. This patch fixes the problem by ensuring there a checkpoint record in the last log file before creating a new log file with new encryption properties and writing the commit log record. Log is also flushed before making the transaction log use the new encryption key to avoid any part of old log records in the buffers getting encrypted with the new encryption key. While working on this problem , I noticed error message thrown incase of re-encryption failures are confusing, added a new error message to indicate failures specific to (re) encryption. /suresh > a crash during re-encryption of an existing database with lot of tables can make database unrecoverable on a next boot. > ------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1786 > URL: http://issues.apache.org/jira/browse/DERBY-1786 > Project: Derby > Issue Type: Bug > Affects Versions: 10.2.1.0, 10.3.0.0 > Reporter: Suresh Thalamati > Assigned To: Suresh Thalamati > Attachments: derby-1786.diff, stk.txt > > > While running reencryt crash/recovery functional test with 1000 tables (>2000 containers) , I hit a following boot failire. > ERROR XJ040: Failed to start database 'wombat_pwd_en', see the next exception fo > r details. > ERROR XSTB0: An exception was thrown during transaction abort. > java.sql.SQLException: Failed to start database 'wombat_pwd_en', see the next ex > ============= begin nested exception, level (1) =========== > ERROR XSRS4: Error renaming file (during backup) from E:\suresht\adhoctests\reencryption\dbs\wombat_pwd_en\seg0\c340.dat to E:\suresht\adhoctests\reencryption\dbs\wombat_pwd_en\seg0\n340.dat. > --- > After bit of debugging ; my suspicion is this problem is happening becuase of more than one log file switch during re-encryption and current > re-encryption recovery code does not seem to handle it correctly. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira