Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 06D07633CE9 for ; Thu, 8 Apr 2010 13:36:46 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 20895-01 for ; Thu, 8 Apr 2010 16:36:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gw.wicourts.gov (gwmta.wicourts.gov [165.219.244.99]) by mail.postgresql.org (Postfix) with ESMTP id 23352634186 for ; Thu, 8 Apr 2010 13:36:35 -0300 (ADT) Received: from Courts-MTA by gw.wicourts.gov with Novell_GroupWise; Thu, 08 Apr 2010 11:36:34 -0500 Message-Id: <4BBDBFBB020000250003059F@gw.wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 08 Apr 2010 11:36:27 -0500 From: "Kevin Grittner" To: "=?ISO-8859-15?Q?Dennis=20Thrys=F8e?=" , Subject: Re: WARM standby with pg_standby References: <1A57E5A7-AEB8-412B-B3A7-D52768F2FCF7@geysirit.dk> In-Reply-To: <1A57E5A7-AEB8-412B-B3A7-D52768F2FCF7@geysirit.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.704 tagged_above=-10 required=5 tests=AWL=-0.594, BAYES_05=-1.11 X-Spam-Level: X-Archive-Number: 201004/90 X-Sequence-Number: 34184 Dennis Thrysøe wrote: > 1) The master keeps writing WAL files even though I'm quite sure > nothing is happening. This seems like a large waste of diskspace? What is your setting for archive_timeout? This limits how long before a WAL file is sent. You could extend the time, although that means that in case of a failure, you might not be as up-to-date. Another option is to use pg_clearxlogtail with gzip or use pglesslog. I haven't used pglesslog, but piping an empty WAL file through pg_clearxlogtail and gzip reduces it to about 16 kB (rather than 16 MB). > 2) Sometimes my slave does not read and delete WAL files when in > recovery mode. This will eventually fill up the disk. Sorry I can't help with that one -- we use our own scripts rather than pg_standby. Anyone else recognize this issue? > pg_controldata gives me: > > Minimum recovery ending location: 0/0 > > What does that mean? I think that only has meaning when the cluster is in archive recovery status. What does pg_controldata say the "Database cluster state" is when you see this? > Is there any good ways of troubleshooting the behaviour, and > finding out precisely what state the slave is in, etc.? We use pg_controldata and check "Database cluster state" to ensure that our warm standbys are still "in archive recovery" and we check the "Time of latest checkpoint" to ensure that its age is not much beyond our archive_timeout setting -- to ensure that the data is indeed still flowing. I believe that 9.0 will be adding some nicer ways to check such things. -Kevin