Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 1C9E31336971 for ; Mon, 3 Jan 2011 14:42:45 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 60065-09 for ; Mon, 3 Jan 2011 18:42:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 94B3F13364DE for ; Mon, 3 Jan 2011 14:42:37 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p03IgWql022501; Mon, 3 Jan 2011 13:42:32 -0500 (EST) To: Scott Ribe cc: Imre Oolberg , pgsql-admin@postgresql.org Subject: Re: Re: pg v. 8.4.5 misses objects and data after restoring from backup using wal In-reply-to: <42066935-6D27-46E3-8094-836D204816B7@elevated-dev.com> References: <4D2213EB.7090700@auul.pri.ee> <42066935-6D27-46E3-8094-836D204816B7@elevated-dev.com> Comments: In-reply-to Scott Ribe message dated "Mon, 03 Jan 2011 11:31:22 -0700" Date: Mon, 03 Jan 2011 13:42:32 -0500 Message-ID: <22500.1294080152@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201101/16 X-Sequence-Number: 36456 Scott Ribe writes: > On Jan 3, 2011, at 11:22 AM, Imre Oolberg wrote: >> But http://www.postgresql.org/docs/9.0/interactive/continuous-archiving.html suggests to use tar on rsync and i guess that PostgreSQL recovery with wal files takes care of these inconsistencies that are created during copying filesystem, right? > Yes, but the database is recovered to the consistent state as of the pg_start_backup command, as I pointed out to you before. Results of transactions that commit after the pg_start_backup command will not be in the backed up database. That's either incorrect or poorly worded. The only way to get a consistent, usable database is to replay all the WAL that was generated between pg_start_backup and pg_stop_backup. That will fix up whatever inconsistencies exist in the base backup fileset. Once you've done that, you do have the results of transactions that committed after pg_start_backup (and up to pg_stop_backup). If you haven't done that, what you have is an inconsistent pile of rather arbitrary bits. The base backup by itself (without the concurrently-created WAL) is *useless*. regards, tom lane