Re: Backup of live database - Mailing list pgsql-admin

From Steve Holdoway
Subject Re: Backup of live database
Date
Msg-id 20080117075536.b03f6077.steve.holdoway@firetrust.com
Whole thread Raw
In response to Re: Backup of live database  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
On Wed, 16 Jan 2008 10:19:12 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Steve Holdoway <steve.holdoway@firetrust.com> writes:
> > You can be absolutely certain that the tar backup of a file that's changed is a complete waste of time. Because it
changedwhile you were copying it.  
>
> That is, no doubt, the reasoning that prompted the gnu tar people to
> make it do what it does, but it has zero to do with reality for
> Postgres' usage in PITR base backups.  What we care about is consistency
> on the page level: as long as each page of the backed-up file correctly
> represents *some* state of that page while the backup was in progress,
> everything is okay, because replay of the WAL log will correct any pages
> that are out-of-date, missing, or shouldn't be there at all.  And
> Postgres always writes whole pages.  So as long as write() and read()
> are atomic --- which is the case on all Unixen I know of --- everything
> works.
>
> (Thinks for a bit...) Actually I guess there's one extra assumption in
> there, which is that tar must issue its reads in multiples of our page
> size.  But that doesn't seem like much of a stretch.
>
>             regards, tom lane

That's OK for the WAL logs, but what about the initial archive - the recovery's got to start somewhere...

Attachment

pgsql-admin by date:

Previous
From: Tom Arthurs
Date:
Subject: Re: Backup of live database
Next
From: "Benjamin Krajmalnik"
Date:
Subject: Strange client encoding issue