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.comPostgreSQL Training, Services and Support
