Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 12330B5DC1F for ; Wed, 29 Jun 2011 22:54:28 -0300 (ADT) 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 75496-02 for ; Thu, 30 Jun 2011 01:54:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp-4.01.com (smtp-4.01.com [38.102.63.183]) by mail.postgresql.org (Postfix) with ESMTP id 3F148B5DC19 for ; Wed, 29 Jun 2011 22:54:21 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-4.01.com (Postfix) with ESMTP id 3CD255985A for ; Wed, 29 Jun 2011 20:54:21 -0500 (CDT) Received: from smtp-4.01.com ([127.0.0.1]) by localhost (smtp-4.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvYCCV5lDi5w for ; Wed, 29 Jun 2011 20:54:21 -0500 (CDT) Received: by smtp-4.01.com (Postfix, from userid 99) id 22F26598F5; Wed, 29 Jun 2011 20:54:21 -0500 (CDT) Received: from Sidney-Stratton.local (70-36-143-92.dsl.dynamic.sonic.net [70.36.143.92]) by smtp-4.01.com (Postfix) with ESMTPSA id C1D175985A for ; Wed, 29 Jun 2011 20:54:20 -0500 (CDT) Message-ID: <4E0BD74B.7020105@agliodbs.com> Date: Wed, 29 Jun 2011 18:54:19 -0700 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: pgsql-hackers@postgresql.org Subject: Re: time-delayed standbys References: <26007.1303309175@sss.pgh.pa.us> <27149.1303312506@sss.pgh.pa.us> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-5 required=5 tests=BAYES_00=-1.9, TO_NO_BRKTS_PCNT=0.001 X-Spam-Level: X-Archive-Number: 201106/2310 X-Sequence-Number: 191023 Robert, > I don't really see how that's any different from what happens now. If > (for whatever reason) the master is generating WAL faster than a > streaming standby can replay it, then the excess WAL is going to pile > up someplace, and you might run out of disk space. Time-delaying the > standby creates an additional way for that to happen, but I don't > think it's an entirely new problem. Not remotely new. xlog partition full is currently 75% of the emergency support calls PGX gets from clients on 9.0 (if only they'd pay attention to their nagios alerts!) > I am not sure exactly how walreceiver handles it if the disk is full. > I assume it craps out and eventually retries, so probably what will > happen is that, after the standby's pg_xlog directory fills up, > walreceiver will sit there and error out until replay advances enough > to remove a WAL file and thus permit some more data to be streamed. Nope, it gets stuck and stops there. Replay doesn't advance unless you can somehow clear out some space manually; if the disk is full, the disk is full, and PostgreSQL doesn't remove WAL files without being able to write files first. Manual (or scripted) intervention is always necessary if you reach disk 100% full. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com