Re: Hot standby, recovery infra

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby, recovery infra
Date: 2009-02-06 08:17:14
Message-ID: 1233908234.4500.653.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.com
PostgreSQL Training, Services and Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2009-02-06 08:40:22 Re: Synch Replication
Previous Message Heikki Linnakangas 2009-02-06 08:06:15 Re: Hot standby, recovery infra