Re: New trigger option of pg_standby
От | Simon Riggs |
---|---|
Тема | Re: New trigger option of pg_standby |
Дата | |
Msg-id | 1242328204.3843.599.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: New trigger option of pg_standby (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: New trigger option of pg_standby
|
Список | pgsql-hackers |
On Fri, 2009-05-15 at 03:49 +0900, Fujii Masao wrote: > Hi, > > On Fri, May 15, 2009 at 12:36 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > > > On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote: > >> On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote: > >> > >> > This whole thing can be considered to be a new feature. > >> > >> recovery.conf will contain a new optional parameter: > >> > >> recovery_end_command (string) > > > > Implemented. > > > + ereport(signaled ? FATAL : WARNING, > > + (errmsg("recovery_end_command \"%s\": return code %d", > > + xlogRecoveryEndCmd, rc))); > > In fast failover case, pg_standby has to delete the trigger file immediately > if it's found. Otherwise, recovery may go wrong as I already described. > http://archives.postgresql.org/pgsql-hackers/2009-04/msg01139.php > > So, in fast mode, recovery_end_command would always fail to delete the > trigger file, and cause warning. This is odd behavior, I think. We should > change WARNING to DEBUG2 like RestoreArchivedFile() in the above code? Using rm -f would avoid the WARNING. I'd rather keep it at WARNING, since not sure what command I'll be running and what a non-zero rc means. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: