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=eAFa5+veFJz6ajW990zrnJ2sBCZXchn0/bCuIztaIhQuMcnJvrxyvrz9U2q5IaVOD2
	nBvCyfwy3tqcUSMe9PtSkwax34ECD+OaU8v14bj9V1CLxR2WvM/PXaEpdQ0fTrxEf2aM
	A7Sxih5uHkABGSQgjk80QxBztyrU/WoyZ0yjw=
MIME-Version: 1.0
In-Reply-To: <3f0b79eb0904092047w355e0b3ar527a9285b161ef91@mail.gmail.com>
References: <3f0b79eb0903242329j12865d55s348f5c873a956e71@mail.gmail.com>
	<49CCBEE0.1080307@gmx.net> <8365.1238163943@sss.pgh.pa.us>
	<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>
Date: Fri, 10 Apr 2009 11:31:47 +0200
Message-ID: <1d4e0c10904100231p43aecd0fhdae48f732d9f264d@mail.gmail.com>
Subject: Re: New trigger option of pg_standby
From: Guillaume Smet <guillaume.smet@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Peter Eisentraut <peter_e@gmx.net>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> One idea to solve this problem is to tell pg_standby as a
> command-line argument about whether the trigger file can be
> removed. That parameter value can be set to 'true' when the last
> applied record is re-fetched. Though pg_standby is called to
> restore timeline history files also after that point, the trigger file
> is already unnecessary (pg_standby doesn't wait for history file).
>
> Specifically, if restore_command contains new % option (%e?),
> it's replaced by the boolean value which indicates whether the
> trigger file can be deleted. This value is set to 'true' when the
> startup process re-fetches the last valid record, 'false' otherwise.
> In smart mode, pg_standby determines whether to delete the
> trigger file according to that value.
>
> Comments?

Hmmm, it seems overly complicated but I don't know the code of pg_standby.

> Or, do you have any better idea?

Wouldn't it be possible to have a global switch (let's name it
startCluster, default to false) which is set to true when the trigger
file is found for the first time? You would then be able to remove the
trigger file and let the cluster start by checking this variable.

One more time, I don't know the code of pg_standby so it may be a stupid idea.

-- 
Guillaume