Re: New trigger option of pg_standby
От | Heikki Linnakangas |
---|---|
Тема | Re: New trigger option of pg_standby |
Дата | |
Msg-id | 49EDAB5B.5040400@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: New trigger option of pg_standby (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: New trigger option of pg_standby
|
Список | pgsql-hackers |
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? > 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: