Subject: Re: New trigger option of pg_standby
From: Simon Riggs <simon@2ndQuadrant.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.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>
In-Reply-To: <3f0b79eb0904122252t1f4c5860v919d199f399ccf72@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>
	<1239381103.16396.30.camel@ebony.2ndQuadrant>
	<3f0b79eb0904122252t1f4c5860v919d199f399ccf72@mail.gmail.com>
Content-Type: text/plain
Date: Tue, 14 Apr 2009 10:35:40 +0100
Message-Id: <1239701740.16396.86.camel@ebony.2ndQuadrant>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2009-04-13 at 14:52 +0900, Fujii Masao wrote:

> A lookahead (the +1) may have pg_standby get stuck as follows.
> Am I missing something?
> 
> 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.

This can't happen. (4) will never occur when (2-2) has occurred. A
non-zero error code means file not available which will cause recovery
to end and hence no requests for further WAL files are made.

It does *seem* as if there is a race condition there in that another WAL
file may arrive after we have taken the decision there are no more WAL
files, but it's not a problem. That could happen if we issue the trigger
while the master is still up, which is a mistake - why would we do that?
If we only issue the trigger once we are happy the master is down then
we don't get a problem.

So lets do it the next+1 way, when triggered.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support