Re: [BUGS] BUG #8043: 9.2.4 doesn't open WAL files from archive, only looks in pg_xlog - Mailing list pgsql-hackers

From Jeff Bohmer
Subject Re: [BUGS] BUG #8043: 9.2.4 doesn't open WAL files from archive, only looks in pg_xlog
Date
Msg-id EBA8264E-9B58-42C7-A596-4264902A38CD@visionlink.org
Whole thread Raw
In response to Re: [BUGS] BUG #8043: 9.2.4 doesn't open WAL files from archive, only looks in pg_xlog  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: [BUGS] BUG #8043: 9.2.4 doesn't open WAL files from archive, only looks in pg_xlog  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Apr 6, 2013, at 1:24 PM, Jeff Janes <jeff.janes@gmail.com> wrote:

> On Sat, Apr 6, 2013 at 1:24 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com>wrote:
>
>>
>> Incidentally, I bumped into another custom backup script just a few weeks
>> back that also excluded backup_label. I don't know what the author was
>> thinking when he wrote that, but it seems to be a surprisingly common
>> mistake. Maybe it's the "label" in the filename that makes people think
>> it's not important.
>
>
>
> I think part of it is the name "label', and part of it is that this file is
> similar to and hence easily confused with the .history files, which (as far
> as I know) truly are there only for human information and not for system
> operation.

While the backup_label file was included in all base backups by the custom backup script, it was not present in the
clusterdirectory when starting PG 9.2.4. Because the data directory was synced from the base backup without
backup_label.Sure enough, including backup_label in the data directory fixes this for me. 

I think these custom scripts were written around 8.1. That the base backups have worked all this time (each base backup
istested) is probably because the backup script, immediately after calling pg_start_backup(), rsyncs pg_control before
rsync'ingeverything else in the data directory. Although, it seems this quirk allows for problems if WAL files are
generatedbetween the time pg_start_backup() is called and pg_control is rsync'd. 


>> Perhaps we should improve the documentation to make it more explicit that
>> backup_label must be included in the backup. The docs already say that,
>> though, so I suspect that people making this mistake have not read the docs
>> very carefully anyway.
>>
>
>
> I don't think the docs are very clear on that.  They say "This file will of
> course be archived as a part of your backup dump file", but "will be" does
> not imply "must be".  Elsewhere it emphasizes that the label you gave to
> pg_start_backup is written into the file, but doesn't really say what the
> file itself is there for.  To me it seems to imply that the file is there
> for your convenience, to hold that label, and not as a critical part of the
> system.
>
> Patch attached, which I hope can be back-patched.  I'll also add it to
> commitfest-Next.
>
> Cheers,
>
> Jeff
> <backup_label_warning_v1.patch>


I think this documentation update would be helpful.

Thank you for your help,
- Jeff
--
Jeff Bohmer | Corporate Technology Manager | VisionLink, Inc.
First National Center | 3101 Iris Avenue, Suite 240 | Boulder CO, 80301

Office 303.402.0170 x121

Other ways to stay in touch - Blog | Twitter | Facebook | LinkedIn | Web

This message and any attachments may contain information that is privileged,
confidential or exempt from disclosure under applicable law or agreement. If you
have received this message in error, please reply and delete the message and
any attachments without opening the attachment. Thank you.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Inconsistent DB data in Streaming Replication
Next
From: Ants Aasma
Date:
Subject: Re: Inconsistent DB data in Streaming Replication