Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id F3482633C01 for ; Wed, 13 Jan 2010 07:36:19 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 37648-03 for ; Wed, 13 Jan 2010 11:36:09 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by mail.postgresql.org (Postfix) with SMTP id A69D9633B8A for ; Wed, 13 Jan 2010 07:36:08 -0400 (AST) Received: from source ([209.85.219.216]) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKS02wJgZTNGoG8Ci+CeAMvrCqQEtfMNCl@postini.com; Wed, 13 Jan 2010 03:36:08 PST Received: by ewy8 with SMTP id 8so873728ewy.12 for ; Wed, 13 Jan 2010 03:36:05 -0800 (PST) Received: by 10.213.100.156 with SMTP id y28mr9928045ebn.68.1263382565365; Wed, 13 Jan 2010 03:36:05 -0800 (PST) Received: from ?192.168.1.117? (dsl-hkibrasgw2-ff67c300-165.dhcp.inet.fi [88.195.103.165]) by mx.google.com with ESMTPS id 10sm11317406eyd.37.2010.01.13.03.36.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 03:36:04 -0800 (PST) Message-ID: <4B4DB022.4070209@enterprisedb.com> Date: Wed, 13 Jan 2010 13:36:02 +0200 From: Heikki Linnakangas Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: PostgreSQL-development Subject: Incrementally Updated Backups and restartpoints Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.589 tagged_above=-10 required=5 tests=BAYES_00=-2.599, FH_DATE_PAST_20XX=3.188 X-Spam-Level: X-Archive-Number: 201001/1343 X-Sequence-Number: 154564 Our documentation suggests that you can take a base backup of a warm standby server while it's running: > If we take a backup of the standby server's data directory while it is processing logs shipped from the primary, we will be able to reload that data and restart the standby's recovery process from the last restart point. We no longer need to keep WAL files from before the restart point. If we need to recover, it will be faster to recover from the incrementally updated backup than from the original base backup. That doesn't seem safe. If the server makes a new restartpoint while the backup is running, and pg_control is backed up after the new restartpoint is made, recovery will restart from the new restartpoint. That is wrong; recovery needs to restart at the restartpoint that was most recent when the backup started. This is basically the same issue we have solved in master with the backup_label file. I wonder if it would be enough to document that pg_control must be backed up first? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com