Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 46174633377 for ; Tue, 21 Apr 2009 08:02:32 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 09503-01 for ; Tue, 21 Apr 2009 08:02:28 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail136041.authsmtp.com (outmail136041.authsmtp.com [62.13.136.41]) by mail.postgresql.org (Postfix) with ESMTP id 9919B633285 for ; Tue, 21 Apr 2009 08:02:27 -0300 (ADT) Received: from mail-c193.authsmtp.com (mail-c193.authsmtp.com [62.13.128.118]) by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n3LB2Ivl074104; Tue, 21 Apr 2009 12:02:18 +0100 (BST) Received: from [10.149.10.145] ([82.194.193.146]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n3LB2Gfj042868; Tue, 21 Apr 2009 12:02:16 +0100 (BST) Subject: Re: New trigger option of pg_standby From: Simon Riggs To: Heikki Linnakangas Cc: Fujii Masao , Guillaume Smet , Tom Lane , Peter Eisentraut , Kevin Grittner , pgsql-hackers In-Reply-To: <49EC8B06.3020204@enterprisedb.com> References: <3f0b79eb0903242329j12865d55s348f5c873a956e71@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> <3f0b79eb0904132241p18084914g792cb8e5ab3eebb3@mail.gmail.com> <3f0b79eb0904150101pb1c59a3ubb422867e8e6a944@mail.gmail.com> <49EC3B01.6050509@enterprisedb.com> <3f0b79eb0904200354u41b54017u16dc73d021c03cdb@mail.gmail.com> <49EC8B06.3020204@enterprisedb.com> Content-Type: text/plain Date: Tue, 21 Apr 2009 12:03:56 +0100 Message-Id: <1240311836.23905.206.camel@ebony.fara.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: e0bc8f9c-2e63-11de-8a51-002264978518 X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksacRtFagRbbElD HGQLW11EUV97WWF/ ag0fZQdDY0NKQQRj U1ZIRlRNFgBqBAMB SEAdLmtwAFMceHpy bUBqEHJYVU00IEYv EUYCHD4bZzJma30e URQNagsFdQJXfh9H aFZ7XXQFZGQPKBg1 TUcAHxkaHhhlExEd ZAwSZU4IQEkEEyR0 QAgeHDIpVUoLDz08 GAc6I1gQFld5 X-Authentic-SMTP: 61633235383639.pelican.dmpriest.net.uk:1562/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200904/1064 X-Sequence-Number: 137167 On Mon, 2009-04-20 at 17:47 +0300, Heikki Linnakangas wrote: > At the end of archive recovery, the server always probes for the > timeline by requesting history files until it fails to find one. That > probing should remove the trigger file if it hasn't been removed by > then. It's a bit coincidental to rely on that, but at least it's simple. > The assumption we're making is that the server won't exit recovery > before asking restore_command for a file that doesn't exist. If you really want to simplify this, then we should have a final_command parameter for a command to be executed at the end of recovery. That would make the change to pg_standby very simple and allow for a very simple final_command also. That would make the logic similar to what we do for aggregates: transition function and final function. We could call it restore_cleanup_command or something similar. I suspect this option will make you consider Fujii-san's patch in a better light. :-) -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support