Re: Hot standby, recovery infra - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Hot standby, recovery infra
Date
Msg-id 1233908234.4500.653.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Hot standby, recovery infra  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Hot standby, recovery infra
List pgsql-hackers
On Fri, 2009-02-06 at 10:06 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-02-05 at 21:54 +0200, Heikki Linnakangas wrote:
> >> - If you perform a fast shutdown while startup process is waiting for 
> >> the restore command, startup process sometimes throws a FATAL error 
> >> which leads escalates into an immediate shutdown. That leads to 
> >> different messages in the logs, and skipping of the shutdown 
> >> restartpoint that we now otherwise perform.
> > 
> > Sometimes?
> 
> I think what happens is that if the restore command receives the SIGTERM 
> and dies before the startup process that's waiting for the restore 
> command receives the SIGTERM, the startup process throws a FATAL error 
> because the restore command died unexpectedly. I put this
> 
> >     if (shutdown_requested && InRedo)
> >     {
> >         /* XXX: Is EndRecPtr always the right value here? */
> >         UpdateMinRecoveryPoint(EndRecPtr);
> >         proc_exit(0);
> >     }
> 
> right after the "system(xlogRestoreCmd)" call, to exit gracefully if we 
> were requested to shut down while restore command was running, but it 
> seems that that's not enough because of the race condition.

Can we trap the death of the restorecmd and handle it differently from
the death of the startup process?

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Hot standby, recovery infra
Next
From: Fujii Masao
Date:
Subject: Re: Synch Replication