Re: Wierd quirk of HS/SR, probably not fixable - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Wierd quirk of HS/SR, probably not fixable
Date
Msg-id v2y3f0b79eb1004271943u65262e18je68fba81adbf6c77@mail.gmail.com
Whole thread Raw
In response to Re: Wierd quirk of HS/SR, probably not fixable  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Wed, Apr 28, 2010 at 4:12 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Simon Riggs wrote:
>> On Tue, 2010-04-27 at 20:14 +0300, Heikki Linnakangas wrote:
>>> Simon Riggs wrote:
>>>> On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
>>>>> Simon Riggs wrote:
>>>>>> 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.
>>>>> It's just as likely that the file is there even though the backup didn't
>>>>> finish, though.
>>>> It's possible, but not likely. It would need to break at a very specific
>>>> place for that to be the case. Whereas the test I explained would work
>>>> for about 99% of the time between start and stop backup, except for the
>>>> caveat I explained also.
>>> I don't understand how you arrived at that figure.
>>
>> You're talking about the backup_label file, I'm talking about
>> the .backup file in the archive.
>
> Oh, the backup history file. We stopped relying on that with the
> introduction of the end-of-backup record, to make life easier for
> streaming replication, and because it's simpler anyway. I don't think we
> should go back to it.

Right.

When restore_command is not given, the backup history file would be
unavailable in the standby. We cannot regard the absence of the file
as non-run of pg_stop_backup().

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Error handling for ShmemInitStruct and ShmemInitHash
Next
From: Craig Ringer
Date:
Subject: Re: Differential backup