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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers