From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Wierd quirk of HS/SR, probably not fixable |
Date: | 2010-04-27 12:58:49 |
Message-ID: | 1272373129.4161.7164.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2010-04-27 at 12:25 +0300, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > On Tue, Apr 27, 2010 at 4:19 PM, Heikki Linnakangas
> > <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> >> Hmm, we could throw an error in the standby, when we see a shutdown
> >> checkpoint while we're waiting for an end-backup record. If the database
> >> was shut down before pg_stop_backup(), we know that the backup was
> >> cancelled and the end-backup record we're waiting for will never arrive.
> >
> > Sounds good. This would work fine even if an immediate shutdown is done
> > instead since the primary ends up generating a shutdown checkpoint record
> > when restarting.
>
> Yep. I've committed a patch to do that.
We should be able to do this earlier in the run.
If pg_stop_backup() is run it creates the .backup file in the archive.
In the absence of that file, we should be able to work out that
pg_stop_backup() was not run. Almost, because we support starting
recovery without need to run start/stop backup. If we introduced a
special option for that in recovery.conf it would be much simpler to
fail if the file were unavailable.
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-04-27 13:10:44 | Re: recovery_connections cannot start |
Previous Message | Robert Haas | 2010-04-27 11:56:51 | Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct |