From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Archive recovery won't be completed on some situation. |
Date: | 2014-03-19 11:54:56 |
Message-ID: | CAHGQGwF+j4B4CMZeAQkiO85AWumwOFpd=vHcK9nXtR9hukZeEQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 03/19/2014 10:28 AM, Kyotaro HORIGUCHI wrote:
>>
>> The*problematic* operation sequence I saw was performed by
>>
>> pgsql-RA/Pacemaker. It stops a server already with immediate mode
>> and starts the Master as a Standby at first, then
>> promote. Focusing on this situation, there would be reasonable to
>> reset backup positions.
>
>
> Well, that's scary. I would suggest doing a fast shutdown instead. But if
> you really want to do an immediate shutdown, you should delete the
> backup_label file after the shutdown
>
> When restarting after immediate shutdown and a backup_label file is present,
> the system doesn't know if the system crashed during a backup, and it needs
> to perform crash recovery, or if you're trying restore from a backup. It
> makes a compromise, and starts recovery from the checkpoint given in the
> backup_label, as if it was restoring from a backup, but if it doesn't see a
> backup-end WAL record, it just starts up anyway (which would be wrong if you
> are indeed restoring from a backup). But if you create a recovery.conf file,
> that indicates that you are definitely restoring from a backup, so it's more
> strict and insists that the backup-end record must be replayed.
>
>
>> 9.4 canceles backup mode even on
>> immediate shutdown so the operation causes no problem, but 9.3
>> and before are doesn't.
>
>
> Hmm, I don't think we've changed that behavior in 9.4.
ISTM 82233ce7ea42d6ba519aaec63008aff49da6c7af changed immdiate
shutdown that way.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-03-19 12:06:51 | Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors |
Previous Message | Sandro Santilli | 2014-03-19 11:43:25 | Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?) |