Subject: Re: New trigger option of pg_standby
From: Simon Riggs <simon@2ndQuadrant.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Fujii Masao <masao.fujii@gmail.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: <49EDC22E.9030506@enterprisedb.com>
References: <3f0b79eb0903242329j12865d55s348f5c873a956e71@mail.gmail.com>
	<3f0b79eb0904132241p18084914g792cb8e5ab3eebb3@mail.gmail.com>
	<3f0b79eb0904150101pb1c59a3ubb422867e8e6a944@mail.gmail.com>
	<49EC3B01.6050509@enterprisedb.com>
	<3f0b79eb0904200354u41b54017u16dc73d021c03cdb@mail.gmail.com>
	<49EC8B06.3020204@enterprisedb.com>
	<1240311836.23905.206.camel@ebony.fara.com>
	<49EDAB5B.5040400@enterprisedb.com>
	<1240313150.23905.222.camel@ebony.fara.com>
	<49EDADD6.1090006@enterprisedb.com>
	<3f0b79eb0904210448l36d9bb27u8b832540010a6f20@mail.gmail.com>
	<49EDC22E.9030506@enterprisedb.com>
Content-Type: text/plain
Date: Tue, 21 Apr 2009 15:05:51 +0100
Message-Id: <1240322751.23905.244.camel@ebony.fara.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Tue, 2009-04-21 at 15:55 +0300, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
> > <heikki.linnakangas@enterprisedb.com> wrote:
> >> Simon Riggs wrote:
> >>> What you propose is *better* than raw pg_standby is now, but still not
> >>> enough in all cases, as I think you know.
> >> No, I don't. What is the case where it doesn't work?
> > 
> > It's the case which I described as the 2nd comment to your
> > proposal.
> > 
> > 1. pg_standby tries to restore a non-existent file
> > 1-1. remove the trigger file
> > 1-2. pg_standby exits with non-zero code
> > 2. the startup process tries to read it from pg_xlog
> > 2-1. it is applied
> > 3. the startup process tries to restore the next file using pg_standby
> > 3-1. pg_standby gets *stuck* since the requested file and trigger file
> >        don't exist.
> 
> Ahh, ok, I didn't understand the issue correctly before.
> 
> But wait a minute, we already have exactly the same problem with the 
> current 8.2/8.3 pg_standby, don't we? [tests]. Yes, we do.
> 
> Simon's suggestion of a separate restore_completion_command is very 
> attractive as it would provide an explicit place to hook up the deletion 
> of the trigger file. It seems useful anyway, you might want to put a 
> command there to e.g update a log file or launch some custom daemon 
> software when the recovery ends. The question then is what to do with 
> 8.2 and 8.3? Even if we decided to keep the behavior that the failover 
> is triggered immediately (fast mode), pg_standby getting stuck if you 
> copy any WAL files directly into pg_xlog seems like a bug that needs to 
> be fixed.
> 
> Fujii's idea of deleting the trigger file when history file is requested 
> is the only proposal this far that works and doesn't require changes to 
> people's config files, so I guess that's what we'll have to do at least 
> for back-branches.

Agreed. Fujii-san's proposal is the only one that covers all the
important things. The assumptions need careful documentation, as you
say.

The idea of a restore_completion_command does still sound attractive,
easy to implement and non-intrusive enough to do so right now.

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