Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 1841B6367BE for ; Thu, 5 Mar 2009 14:15:57 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 10779-04 for ; Thu, 5 Mar 2009 14:15:54 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail1.chappy.com (mail1.chappy.com [67.132.255.10]) by mail.postgresql.org (Postfix) with ESMTP id 124306348D5 for ; Thu, 5 Mar 2009 13:13:34 -0400 (AST) Received: from nas01.chappy.com (nas01.chappy.com [192.168.40.21]) by mail1.chappy.com (Postfix) with ESMTP id 27F226C01E for ; Thu, 5 Mar 2009 10:04:45 -0500 (EST) Received: from tech-pc04.chappy.com (tech-pc04.chappy.com [192.168.105.223]) by nas01.chappy.com (Postfix) with ESMTP id D6E3C63EC3 for ; Thu, 5 Mar 2009 10:04:44 -0500 (EST) From: Yauheni Labko Reply-To: yyl@chappy.com Organization: Chapdelaine & Co To: pgsql-admin@postgresql.org Subject: Re: standby waiting for what? Date: Thu, 5 Mar 2009 10:04:44 -0500 User-Agent: KMail/1.9.9 References: <20090304200612.GA25611@cns.vt.edu> <200903041705.19794.yyl@chappy.com> <20090305135556.GA9900@cns.vt.edu> In-Reply-To: <20090305135556.GA9900@cns.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903051004.44932.yyl@chappy.com> X-Chappy-MailScanner: Found to be clean X-Chappy-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.399, required 5, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Chappy-MailScanner-From: yyl@chappy.com X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200903/75 X-Sequence-Number: 31575 > my recovery command is: > restore_command='/usr/local/pgsql/bin/pg_standby > /data/pgsql/wals/alerts_oamp %f %p %r >> > /home/postgresql/log/alerts_oamp/recovery.log' You gave the recovery command, not the archive command. And give a piece of log file where primary server performs archiving WAL files. > I don't follow you here. How did you know that the string, > 00000002000000000000001C.00512178.backup will provide the start and > end of WAL segment? Please explain how you determined this? *.backup files are ASCII files. They're described at 24.3.2 section of postgres documentation. > I have a suspicion that if I mv > /data/pgsql/wals/alerts_oamp/00000002000000000000001C to > /data/pgsql/wals/alerts_oamp/00000002000000000000001C.00512178.backup that > the recovery would pick up. If there is no understanding to be gained > here, I might do that and then throw this out with the bath water and start > over. May be you will fix the problem at this point. But you will never know why database server wants to grab this file. > confusion. I'm just rsyncing the cluster dir from the primary to the > standby, removing pg_xlogs files, and setting recovery.conf. Is there > a better way? I think you have problem at this point. Did you switch primary database server into backup mode? Where are the archived WAL files? Did you switch primary database server back into normal operation mode after rsyncing? Yauheni Labko (Eugene Lobko) Junior System Administrator Chapdelaine & Co. (212)208-9150