Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id C1ECF632F06 for ; Mon, 15 Feb 2010 02:30:12 -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 03222-08 for ; Mon, 15 Feb 2010 06:30:00 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mail.postgresql.org (Postfix) with ESMTP id 0DD6F6326E8 for ; Mon, 15 Feb 2010 02:30:01 -0400 (AST) Received: by gxk10 with SMTP id 10so3918574gxk.3 for ; Sun, 14 Feb 2010 22:30:00 -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=u/xvDKzWGAP0Xp5l8ErYTjRY3S7lirHfUdRVIBoXKXs=; b=wZl4RfQrTarHtOpcEbybXkZK0U+w4jv7TZZ8bsRpLrWelRjjocZCVEvk54gj05KK6W Eyqpibmg4Fzzx6yRJKqJcVfAdPBsPSelgld3xk8af7/OrJWG7YE1Z0rZhc43Gis2nU6I p12lSmN5mKx4ZTSLfX6rsXViOZavsT6y162DU= 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=IXpD9gjAd8dA7s0PNgW7fa2yuhkNQ8Wsm41PDOtpucRWf8sVlw2saQsz2g3vGsZcuF ZtnA1gRLRpTdyxRQXUHSeKmh6kgp8DVkelH3AFGtT3dCVJywxc/owkko69ygz2WEo9ep /TKdZL1p29PxsCnBO4u1RQ8JDtmt9u0ekuSOU= MIME-Version: 1.0 Received: by 10.150.194.16 with SMTP id r16mr8965884ybf.194.1266215397310; Sun, 14 Feb 2010 22:29:57 -0800 (PST) In-Reply-To: <4B757D5D.3070506@enterprisedb.com> References: <20100127152751.3B2047541B9@cvs.postgresql.org> <1265896250.7341.1627.camel@ebony> <4B740C6C.3010607@enterprisedb.com> <1265897834.7341.1714.camel@ebony> <4B7412BE.5030605@enterprisedb.com> <3f0b79eb1002112138n61a3258fg9986e50751d44ea0@mail.gmail.com> <1265979080.7341.3679.camel@ebony> <4B75533D.2000703@enterprisedb.com> <3f0b79eb1002120747q3203bed6ue1bd07558ec2e38b@mail.gmail.com> <4B757D5D.3070506@enterprisedb.com> Date: Mon, 15 Feb 2010 15:29:57 +0900 Message-ID: <3f0b79eb1002142229k639aad8dk7233175c5484ef6d@mail.gmail.com> Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL From: Fujii Masao To: Heikki Linnakangas Cc: Simon Riggs , Dimitri Fontaine , PostgreSQL-development Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.001 tagged_above=-10 required=5 tests=AWL=0.598, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/1174 X-Sequence-Number: 157517 On Sat, Feb 13, 2010 at 1:10 AM, Heikki Linnakangas wrote: > Are you thinking of a scenario where remove_command gets stuck, and > prevents bgwriter from performing restartpoints while it's stuck? Yes. If there is the archive in the remote server and the network outage happens, remove_command might get stuck, I'm afraid. > You > have trouble if restore_command gets stuck like that as well, so I think > we can require that the remove_command returns in a reasonable period of > time, ie. in a few minutes. Oh, you are right! BTW, we need to note that remove_command approach would be useless if one archive is shared by multiple standbys. One standby might wrongly remove the archived WAL file that has been still required for another standby. In this case, we need to have the job script that calculates the archived WAL files that are required by no standbys, and removes them. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center