Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 4F187632CB7 for ; Wed, 24 Mar 2010 23:08:19 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 88615-01 for ; Thu, 25 Mar 2010 02:08:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mail.postgresql.org (Postfix) with ESMTP id C684E633607 for ; Wed, 24 Mar 2010 23:08:08 -0300 (ADT) Received: by gxk6 with SMTP id 6so5272928gxk.14 for ; Wed, 24 Mar 2010 19:08:06 -0700 (PDT) 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=ZHcKXnNbEEW0k1sl7sBSr020l3MQJlufaoVt7PHYS44=; b=ei126sJ2QYTMxkwaKZrDeKPgpMgw7ATXIX4cylmisQE2qV5315q73co4E9DTcDfR2/ sQdNJOSatZl5c3O6g0po0Psw4AafjhmIZS341Qa78tXuF1lld+tGOTqdLdrRmzzcPcwh 6KuK1OjlmTsCblZyfkvGYY1s8E1ramSptamPA= 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=rDx1xn9LmPL/LIXogXqotD9DER6atAczQWNahgvhGe0ZxAOlXqq+uTlL40rB3Zlf+0 cRCdDxG1Q0wb3d/WnAmZSM1rrPxjLfAQ0blWNtkKJ3WtpqdJjRc+ntvjNkm9IrIqez4E Yzd04sV36JR5ajqQVg91S1hmQ+DLfUrKruN7A= MIME-Version: 1.0 Received: by 10.100.55.22 with SMTP id d22mr2382712ana.82.1269482886628; Wed, 24 Mar 2010 19:08:06 -0700 (PDT) In-Reply-To: <1269472981.8481.8946.camel@ebony> References: <3f0b79eb1002092105r21e009d3v468496058ba04392@mail.gmail.com> <4B743E7D.5070603@enterprisedb.com> <3f0b79eb1002180337t1fab1395ve3491256672af15f@mail.gmail.com> <4BA0B079.3050301@enterprisedb.com> <3f0b79eb1003180727g7877743eq81274e014fe70a49@mail.gmail.com> <1268988724.3556.3.camel@ebony> <4BA361E4.7020309@enterprisedb.com> <3f0b79eb1003230017v16f4ecbeyc20e75beeffe8f1c@mail.gmail.com> <4BAA060A.2020000@enterprisedb.com> <1269472981.8481.8946.camel@ebony> Date: Thu, 25 Mar 2010 11:08:06 +0900 Message-ID: <3f0b79eb1003241908n1e8f38e0q7cd7465163b3d7af@mail.gmail.com> Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL From: Fujii Masao To: Simon Riggs Cc: Heikki Linnakangas , Aidan Van Dyk , PostgreSQL-development Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/996 X-Sequence-Number: 159772 On Thu, Mar 25, 2010 at 8:23 AM, Simon Riggs wrote: > PANICing won't change the situation, so it just destroys server > availability. If we had 1 master and 42 slaves then this behaviour would > take down almost the whole server farm at once. Very uncool. > > You might have reason to prevent the server starting up at that point, > when in standby mode, but that is not a reason to PANIC. We don't really > want all of the standbys thinking they can be the master all at once > either. Better to throw a serious ERROR and have the server still up and > available for reads. OK. How about making the startup process emit WARNING, stop WAL replay and wait for the presence of trigger file, when an invalid record is found? Which keeps the server up for readonly queries. And if the trigger file is found, I think that the startup process should emit a FATAL, i.e., the server should exit immediately, to prevent the server from becoming the primary in a half-finished state. Also to allow such a halfway failover, we should provide fast failover mode as pg_standby does? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center