On Tue, Apr 1, 2014 at 12:39 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Monday, March 31, 2014, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Fri, Mar 28, 2014 at 1:06 AM, Kyotaro HORIGUCHI
>> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>> > Mmm. I don't think it is relevant to this problem. The problem
>> > specific here is 'The database was running until just now, but
>> > shutdown the master (by pacemaker), then restart, won't run
>> > anymore'. Deleting backup_label after immediate shutdown is the
>> > radical measure but existing system would be saved by the option.
>>
>> I don't find that very radical at all. The backup_label file is
>> *supposed* to be removed on the master if it crashes during the
>> backup; and it should never be removed from the backup itself. At
>> least that's how I understand it. Unfortunately, people too often
>> remove the file from the backup and, judging by your report, leave it
>> there on the master.
>
> At first blush it seems pretty radical to me. Just because the server was
> e-stopped doesn't mean the backup rsync/cp -r/scp etc. isn't still running,
> and it is not clear to me that yanking the backup label file out from under
> it wouldn't cause problems. I mean, you already have problems if you are
> trying to restore from that backup, but the missing file might make those
> problems less obvious.
>
> Of course first blush is often wrong, but...
Well, I guess I was thinking mostly of the case where the whole
server's been restarted, in which case none of that stuff is still
running any more. If there is only a database server crash, then I
agree it's murkier. Still, you probably ought to kill off those
things if the database server crashes, and then restart the whole base
backup. Otherwise I think you're going to be in trouble whether the
backup label file sticks around or not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company