Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 629599FB54A for ; Mon, 25 Jun 2007 14:10:54 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 74826-08 for ; Mon, 25 Jun 2007 14:10:51 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id F0A529FB3D7 for ; Mon, 25 Jun 2007 14:10:50 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l5PHAjA6000975; Mon, 25 Jun 2007 13:10:45 -0400 (EDT) To: "Simon Riggs" cc: "Dan Gorman" , "Koichi Suzuki" , "Toru SHIMOGAKI" , pgsql-performance@postgresql.org Subject: Re: PITR Backups In-reply-to: <1182790567.9276.609.camel@silverbirch.site> References: <7E0807EE-B970-4869-A248-B838E42AD9EE@hi5.com> <9761.1182472005@sss.pgh.pa.us> <467B3459.9030808@oss.ntt.co.jp> <1182509748.9276.178.camel@silverbirch.site> <467F938F.1030708@oss.ntt.co.jp> <1182777963.9276.582.camel@silverbirch.site> <367.1182789258@sss.pgh.pa.us> <1182790567.9276.609.camel@silverbirch.site> Comments: In-reply-to "Simon Riggs" message dated "Mon, 25 Jun 2007 17:56:06 +0100" Date: Mon, 25 Jun 2007 13:10:45 -0400 Message-ID: <974.1182791445@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/581 X-Sequence-Number: 25614 "Simon Riggs" writes: >> Reformatting and sorting, we have >> >> WARNING: page 28900 of relation 1663/16384/76718 was uninitialized >> WARNING: page 28902 of relation 1663/16384/76718 was uninitialized >> WARNING: page 26706 of relation 1663/16384/76719 was uninitialized >> WARNING: page 26708 of relation 1663/16384/76719 was uninitialized > Those two are interesting because we appear to have two valid pages in > the middle of some uninitialized ones. That implies were not looking at > an unapplied truncation. Not necessarily --- it's possible the WAL sequence simply didn't touch those pages. Your suggestion to rerun the recovery with higher log_min_messages is a good one, because that way we'd get some detail about what the WAL records that touched the pages were. I think DEBUG1 would be sufficient for that, though, and DEBUG2 might be pretty durn verbose. regards, tom lane