Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 0F2EFB5DBC9 for ; Wed, 29 Jun 2011 22:56:48 -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 73743-09 for ; Thu, 30 Jun 2011 01:56:41 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ew0-f46.google.com (mail-ew0-f46.google.com [209.85.215.46]) by mail.postgresql.org (Postfix) with ESMTP id 83BB6B5DBE5 for ; Wed, 29 Jun 2011 22:56:41 -0300 (ADT) Received: by ewy4 with SMTP id 4so616523ewy.19 for ; Wed, 29 Jun 2011 18:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Pc8NtNXPT0IAiiHqz1CRE/eIBvxV63gr7G4se88TYgE=; b=e1wFWkY0LHoRqnJvLmJozqrcD7zd0P1zl1HA0ETeAtMiYFg2xvoyszDjqSls1++BYs mMNKfuYwwvmZXDELoXMIN8rKb8naIM2wyc1etWkdXRGzdk0sH29uYj+iz+UM3VZUQbP0 AomDsHgq8PW1esnMzWWnso0ltg5S664TgRxic= MIME-Version: 1.0 Received: by 10.14.188.131 with SMTP id a3mr420119een.219.1309399001291; Wed, 29 Jun 2011 18:56:41 -0700 (PDT) Received: by 10.14.96.80 with HTTP; Wed, 29 Jun 2011 18:56:41 -0700 (PDT) In-Reply-To: <4E0BD74B.7020105@agliodbs.com> References: <26007.1303309175@sss.pgh.pa.us> <27149.1303312506@sss.pgh.pa.us> <4E0BD74B.7020105@agliodbs.com> Date: Wed, 29 Jun 2011 21:56:41 -0400 Message-ID: Subject: Re: time-delayed standbys From: Robert Haas To: Josh Berkus Cc: pgsql-hackers@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, FREEMAIL_FROM=0.001 X-Spam-Level: X-Archive-Number: 201106/2313 X-Sequence-Number: 191026 On Wed, Jun 29, 2011 at 9:54 PM, Josh Berkus wrote: >> 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. =A0Replay 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. Wow, that's a pretty crappy failure mode... but I don't think we need to fix it just on account of this patch. It would be nice to fix, of course. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company