Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id E5DEE632781 for ; Mon, 13 Apr 2009 07:21:50 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 34226-03 for ; Mon, 13 Apr 2009 07:21:43 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-fx0-f174.google.com (mail-fx0-f174.google.com [209.85.220.174]) by mail.postgresql.org (Postfix) with ESMTP id ED6016322A0 for ; Mon, 13 Apr 2009 07:21:47 -0300 (ADT) Received: by fxm22 with SMTP id 22so4030791fxm.19 for ; Mon, 13 Apr 2009 03:21:44 -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 :content-transfer-encoding; bh=6BhcT3e056fg5PiseJJdV92OnPGocMX4HmcN78nnVVk=; b=P0xTHpXvjS4dX7nJslgE3Lh6Qq3uFPb6Qd2Gahx2TVQLAMJ3yxvpFbJMppsqoWp3ra SOGwmaHzT4IHblkMHcfXxqpC0gu+lnZ5rg/COMCxY/pc7htLoinwrHkBnWC1iaLGqco3 J4LJ9NHHQPZl6BnWDWzbWdGt/vYF0EkTtw9nY= 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:content-transfer-encoding; b=M73Ap4Km5hO52946WykXPgfXVg1FNMzEOrg19eIpYiqOnAOIxPxa3QFhs81+nuDRY5 tvKQnnlNdo2TMQXP1LD8uiVZcuRCXIr5BK3b3ZMNTxHerzcOAevBWSPAJH2ceYddhhhJ rAECcUiDsm+x4YCG2zhzqbFaeHEXrmFjv1B5I= MIME-Version: 1.0 Received: by 10.223.107.68 with SMTP id a4mr1686502fap.44.1239618101484; Mon, 13 Apr 2009 03:21:41 -0700 (PDT) In-Reply-To: <3f0b79eb0904122252t1f4c5860v919d199f399ccf72@mail.gmail.com> References: <3f0b79eb0903242329j12865d55s348f5c873a956e71@mail.gmail.com> <1238164596.16568.604.camel@ebony.2ndQuadrant> <3f0b79eb0903311901h70520cc8u9c0f1d8f4193923b@mail.gmail.com> <3f0b79eb0904022042g35b8e3cah9432ff764e721a3@mail.gmail.com> <1d4e0c10904071456m735e3f67q123b87243d2f6f2a@mail.gmail.com> <3f0b79eb0904071817u5c32254ei61f7e68e54669d9e@mail.gmail.com> <49DDEE72.6030803@enterprisedb.com> <3f0b79eb0904092047w355e0b3ar527a9285b161ef91@mail.gmail.com> <1239381103.16396.30.camel@ebony.2ndQuadrant> <3f0b79eb0904122252t1f4c5860v919d199f399ccf72@mail.gmail.com> Date: Mon, 13 Apr 2009 12:21:41 +0200 Message-ID: <1d4e0c10904130321i14906f08g1d8863dfe0b6ff7@mail.gmail.com> Subject: Re: New trigger option of pg_standby From: Guillaume Smet To: Fujii Masao Cc: Simon Riggs , Heikki Linnakangas , Tom Lane , Peter Eisentraut , Kevin Grittner , pgsql-hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.142 tagged_above=0 required=5 tests=AWL=0.142 X-Spam-Level: X-Archive-Number: 200904/692 X-Sequence-Number: 136795 On Mon, Apr 13, 2009 at 7:52 AM, Fujii Masao wrote: > 1. the trigger file containing "smart" is created. > 2. pg_standby is executed. > 2-1. nextWALfile is restored. > 2-2. the trigger file is deleted because nextWALfile+1 doesn't exist. > 3. the restored nextWALfile is applied. > 4. pg_standby is executed again to restore nextWALfile+1. I don't think it should happen. IMHO, it's an acceptable compromise to replay all the WAL files present when I created the trigger file. So if I have the smart shutdown trigger file and I don't have any nextWALfile+1, I can remove the trigger file and stop the recovery: pg_standby won't be executed again after that, even if a nextWALfile+1 appeared while replaying the previous WAL file. That said, stupid question: do we have a way to know the nextWALfile+1 name to test if it exists? nextWALfile is transmitted through the restore_command API and I'm wondering if we can have nextWALfile+1 name without changing the restore_command API. -- Guillaume