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: <49EDAB5B.5040400@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>
	<49EC3B01.6050509@enterprisedb.com>
	<3f0b79eb0904200354u41b54017u16dc73d021c03cdb@mail.gmail.com>
	<49EC8B06.3020204@enterprisedb.com>
	<1240311836.23905.206.camel@ebony.fara.com>
	<49EDAB5B.5040400@enterprisedb.com>
Content-Type: text/plain
Date: Tue, 21 Apr 2009 12:25:50 +0100
Message-Id: <1240313150.23905.222.camel@ebony.fara.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Tue, 2009-04-21 at 14:17 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2009-04-20 at 17:47 +0300, Heikki Linnakangas wrote:
> > 
> >> At the end of archive recovery, the server always probes for the 
> >> timeline by requesting history files until it fails to find one. That 
> >> probing should remove the trigger file if it hasn't been removed by 
> >> then. It's a bit coincidental to rely on that, but at least it's simple. 
> >> The assumption we're making is that the server won't exit recovery 
> >> before asking restore_command for a file that doesn't exist.
> > 
> > If you really want to simplify this, then we should have a final_command
> > parameter for a command to be executed at the end of recovery. That
> > would make the change to pg_standby very simple and allow for a very
> > simple final_command also. That would make the logic similar to what we
> > do for aggregates: transition function and final function. 
> > 
> > We could call it restore_cleanup_command or something similar.
> 
> Hmm, that might indeed be a cleaner interface. However, that throws the 
> idea of backpatching out of the window, and will make it impossible to 
> run a PG 8.4 pg_standby against a PG 8.3 server. Do we want to add the 
> new parameter for 8.4 anyway?

Perhaps, let's see how we resolve the perceived 8.2 and 8.3 issues.

> > I suspect this option will make you consider Fujii-san's patch in a
> > better light. :-)
> 
> No, removing trigger file as soon as a non-existant file is requested 
> still seems simpler than deleting it whenever a timeline history file is 
> requested.

If you do this, then you would have to change the procedure written into
the 8.3 docs also. Docs aren't backpatchable.

What you propose is *better* than raw pg_standby is now, but still not
enough in all cases, as I think you know. Simple isn't the requirement
here, is it?

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