Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id B1188632D1B for ; Wed, 10 Feb 2010 05:19:13 -0400 (AST) 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 03814-07 for ; Wed, 10 Feb 2010 09:18:58 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-yx0-f188.google.com (mail-yx0-f188.google.com [209.85.210.188]) by mail.postgresql.org (Postfix) with ESMTP id EC4AF632CCC for ; Wed, 10 Feb 2010 05:19:02 -0400 (AST) Received: by yxe26 with SMTP id 26so8005933yxe.28 for ; Wed, 10 Feb 2010 01:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GrKKY3Q35VRs1J8PgBBbus5GHHRc0yuM0+ZaAcSuWw4=; b=pYiA5o/1cRSIGjGk4U9wcRYD1e1qT7bglG0HzUzgR6JxPy4Xl0ygysCDt/6r/DK3wj +xGmZde+B3b5uZOCOfYQFONBADWGdqXVCzgKJJJyQmhOiFBSR042Q1NMvKCG2AdiERGW 5zf4pZfglhH06/r11MzZUMS9dpMQ2GCoeaK+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=h26HU+lVf1sZaA3Lvyy+MKqfw6dXZyLh61Lksi4rSgHV4OMfm/x75yWNSY52frwpkS N0uk5nDU1DUGyNnIur7cD1oLAjoiwZZqMlNvQ2p4xn7UcuABASW40mKGTEeVU0/FRDtP Cb1bVi4r0D0JhGLqyGNA23mIOw1iW/gtlHT5c= MIME-Version: 1.0 Received: by 10.101.133.34 with SMTP id k34mr4994281ann.213.1265793541823; Wed, 10 Feb 2010 01:19:01 -0800 (PST) In-Reply-To: <4B726120.80007@enterprisedb.com> References: <20100127152751.3B2047541B9@cvs.postgresql.org> <3f0b79eb1002092105r21e009d3v468496058ba04392@mail.gmail.com> <4B726120.80007@enterprisedb.com> Date: Wed, 10 Feb 2010 18:19:01 +0900 Message-ID: <3f0b79eb1002100119r6ce1b4b7haf2732d5fa8bbfa1@mail.gmail.com> Subject: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL From: Fujii Masao To: Heikki Linnakangas Cc: PostgreSQL-development Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.962 tagged_above=-10 required=5 tests=AWL=0.637, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/720 X-Sequence-Number: 157063 On Wed, Feb 10, 2010 at 4:32 PM, Heikki Linnakangas wrote: > Hmm, so after running restore_command, check the file size and if it's > too short, treat it the same as if restore_command returned non-zero? Yes, only in standby mode case. OTOH I think that normal archive recovery should treat it as a FATAL error. > And it will be retried on the next iteration. Works for me, though OTOH > it will then fail to complain about a genuinely WAL file that's > truncated for some reason. I guess there's no way around that, even if > you have a script as restore_command that does the file size check, it > will have the same problem. Right. But the server in standby mode also needs to complain about that? We might be able to read completely such a WAL file that looks truncated from the primary via SR, or from the archive after a few seconds. So it's odd for me to give up continuing the standby only by finding the WAL file whose file size is short. I believe that the warm standby (+ pg_standby) also is based on that thought. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center