Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 9B4A76328C8 for ; Wed, 24 Mar 2010 23:14:56 -0300 (ADT) 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 02561-07 for ; Thu, 25 Mar 2010 02:14:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 0A206632269 for ; Wed, 24 Mar 2010 23:14:45 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o2P2Eb9w006199; Wed, 24 Mar 2010 22:14:37 -0400 (EDT) To: Fujii Masao cc: Simon Riggs , Heikki Linnakangas , Aidan Van Dyk , PostgreSQL-development Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL In-reply-to: <3f0b79eb1003241908n1e8f38e0q7cd7465163b3d7af@mail.gmail.com> 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> <3f0b79eb1003241908n1e8f38e0q7cd7465163b3d7af@mail.gmail.com> Comments: In-reply-to Fujii Masao message dated "Thu, 25 Mar 2010 11:08:06 +0900" Date: Wed, 24 Mar 2010 22:14:37 -0400 Message-ID: <6198.1269483277@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.462 tagged_above=-10 required=5 tests=AWL=0.137, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/997 X-Sequence-Number: 159773 Fujii Masao writes: > 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? I find it extremely scary to read this sort of blue-sky design discussion going on now, two months after we were supposedly feature-frozen for 9.0. We need to be looking for the *rock bottom minimum* amount of work to do to get 9.0 out the door in a usable state; not what would be nice to have later on. regards, tom lane