X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 5A9E0D1B1D9 for ; Tue, 13 Jul 2004 18:19:58 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 73391-03 for ; Tue, 13 Jul 2004 21:19:57 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 238EFD1B1AB for ; Tue, 13 Jul 2004 18:19:55 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i6DLJuEc018740; Tue, 13 Jul 2004 17:19:56 -0400 (EDT) To: Simon Riggs Cc: pgsql-hackers@postgresql.org Subject: Re: Point in Time Recovery In-reply-to: <1089750349.17493.3092.camel@stromboli> References: <1089060299.17493.58.camel@stromboli> <4263.1089064016@sss.pgh.pa.us> <1089150005.17493.270.camel@stromboli> <1089718702.17493.2527.camel@stromboli> <15780.1089728984@sss.pgh.pa.us> <1089750349.17493.3092.camel@stromboli> Comments: In-reply-to Simon Riggs message dated "Tue, 13 Jul 2004 21:25:50 +0100" Date: Tue, 13 Jul 2004 17:19:56 -0400 Message-ID: <18739.1089753596@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200407/705 X-Sequence-Number: 56266 Simon Riggs writes: > I'm getting carried away with the improbable....but this is the rather > strange, but possible scenario I foresee: > A sequence of times... > 1. We start archiving xlogs > 2. We take a checkpoint > 3. we commit an important transaction > 4. We take a backup > 5. We take a checkpoint > When we specify a recovery target, it is possible to specify the > rollforward to complete just before point 3. No, it isn't possible. The recovery *must* proceed at least as far as wherever the end of the log was at the time the backup was completed. Otherwise everything is broken, not only clog, because you may have disk blocks in your backup that postdate where you stopped log replay. To have a consistent recovery at all, you must replay the log starting from a checkpoint before the backup began and extending to the time that the backup finished. You only get to decide where to stop after that point. regards, tom lane