Re: New trigger option of pg_standby - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: New trigger option of pg_standby
Date
Msg-id 1242328204.3843.599.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: New trigger option of pg_standby  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: New trigger option of pg_standby
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: New trigger option of pg_standby
Next
From: Kevin Field
Date:
Subject: Re: pg_views definition format