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=TdTj7TwtfelK3XDEdBCAjP4xuOK19Ct43xbLNtV4xY/gDS+7cU6BJL5gMkDrOepWq7
	tVDRtQzbuCOjX4fsmlEsok2kPfxVO2q3Wua0KSfjsrz3AwzKeYTusojVuu5DjKme13vU
	FHuhPzZh0CvAUN79BYN7oJZauCW90UX+/0WfE=
MIME-Version: 1.0
In-Reply-To: <1d4e0c10904100231p43aecd0fhdae48f732d9f264d@mail.gmail.com>
References: <3f0b79eb0903242329j12865d55s348f5c873a956e71@mail.gmail.com>
	<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>
	<1d4e0c10904100231p43aecd0fhdae48f732d9f264d@mail.gmail.com>
Date: Mon, 13 Apr 2009 12:44:49 +0900
Message-ID: <3f0b79eb0904122044j47583097j58151aad80955de9@mail.gmail.com>
Subject: Re: New trigger option of pg_standby
From: Fujii Masao <masao.fujii@gmail.com>
To: Guillaume Smet <guillaume.smet@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

Hi,

On Fri, Apr 10, 2009 at 6:31 PM, Guillaume Smet
<guillaume.smet@gmail.com> wrote:
> 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.

Yes, I'd also like to simplify it more.

>> 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.

Thanks for the suggestion!

Since pg_standby is executed for each file, such variable cannot
be taken over to the next execution, i.e. it's reset each time. So,
the current patch have left the trigger file until the end.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center