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=l25BseEpVCr20Rz/iqpcpBvX7thcSsFM4XVOVBp3OofVKtwWPsYOFm68tWFck0vUa/
	8l5SWYV58LTzPYPbFtHYb2qiwaQWEUsEHfk2gVhQLZr3wqV2I4IJIfEX4oXybmzEEqcC
	8QJSMl7t7iY8KhPl6QkmBYfTEKq7NyLMSBJ4M=
MIME-Version: 1.0
In-Reply-To: <49EE1E3F.9050307@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>
	<49EE1E3F.9050307@enterprisedb.com>
Date: Wed, 22 Apr 2009 14:09:17 +0900
Message-ID: <3f0b79eb0904212209i7fbd8b68k71db1fef09c62751@mail.gmail.com>
Subject: Re: New trigger option of pg_standby
From: Fujii Masao <masao.fujii@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Simon Riggs <simon@2ndquadrant.com>,
	Guillaume Smet <guillaume.smet@gmail.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,

Thanks for reviewing the patch!

On Wed, Apr 22, 2009 at 4:27 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Fujii Masao wrote:
>>
>> Hi,
>>
>> On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao <masao.fujii@gmail.com>
>> wrote:
>>>
>>> I'd like to propose another simple idea; pg_standby deletes the
>>> trigger file *whenever* the nextWALfile is a timeline history file.
>>> A timeline history file is restored at the end of recovery, so it's
>>> guaranteed that the trigger file is deleted whether nextWALfile
>>> exists or not.
>>>
>>> A timeline history file is restored also at the beginning of
>>> recovery, so the accidentally remaining trigger file is deleted
>>> in early warm-standby as a side-effect of this idea.
>>
>> Here is the revised patch as above.
>>
>> If you notice something, please feel free to comment.
>
> Ok, looking at this in more detail now. A couple of small things:
>
> We mustn't remove the trigger file immediately even in fast mode. As noted
> elsewhere in this thread, we have the same bug in fast mode where pg_standby
> gets stuck if you copy WAL files directly into pg_xlog.

Yes, there is the same problem also in fast mode. But, in fast
mode, the trigger file has to be deleted immediately if it's found.
Otherwise, recovery may fail as follows.

1. pg_standby finds the trigger file for fast mode, and returns
    non-zero without deleting the trigger file.
2. the startup process tries to read the WAL file from pg_xlog,
    but it's not found.
3. the startup process tries to restore the last applied WAL file
    using pg_standby.
4. (Again) pg_standby finds the trigger file for fast mode, and
    returns non-zero without deleting the trigger file.
5. the startup process tries to read the last applied WAL file,
    but it's not found.
    (though the last applied file was of course restored before,
     the restored one cannot be read here)
6. recovery fails because the last applied WAL file cannot be
    read.

On the other hand, if pg_standby returns 0 also in fast mode
when the requested file and trigger file exist, ISTM that there
is not much difference between fast and smart mode; also in
fast mode, all the available WAL files would be applied.

So, I left fast mode as it was (as much as possible) though it has
the above problem, which is for backward compatibility.

Regards,

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