Skip site navigation (1) Skip section navigation (2)

Re: PITR bad restore possibility?

From: Rod Taylor <pg(at)rbt(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PITR bad restore possibility?
Date: 2005-04-28 00:40:54
Message-ID: 1114648854.14522.66.camel@home (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2005-04-27 at 20:14 -0400, Tom Lane wrote:
> Rod Taylor <pg(at)rbt(dot)ca> writes:
> > What happens if for reasons of broken tape, disk, etc. you lose some of
> > your WAL logs which happens to correspond to the middle of the snapshot
> > backup?
> 
> You're screwed ... just like if you lost part of the snapshot itself.
> 
> If you're really lucky the missing WAL logs don't contain any data
> that's not in the snapshot, but I sure wouldn't trust it.

I realize that data would be lost from the point the logs cut off, but
is there any chance of database corruption because the snapshot contains
transaction IDs in tables but possibly not a complete pg_clog or
pg_subtrans directory or vice-versa (pg_clog is complete, but heap files
wouldn't be)?

If WALs cut off at transaction 10, and heaps contain up to transaction
20, WAL makes sure pg_clog is updated to 10 but would a commit from
transaction 11 through 20 make the heap data visible again even though
it wasn't fully restored from WAL?

PostgreSQL doesn't seem to complain if the WAL records cut off before
the PIT that the pg_stop_transaction() was called at during the restore
process, but I'm not entirely sure if it is a corrupt restore (and we
need to go back to an older snapshot and start over playing up until the
WAL records cut off) or whether it's a usable restore ready for
production use.

-- 


In response to

pgsql-hackers by date

Next:From: Juan Jose Costello LevienDate: 2005-04-28 00:53:39
Subject: Re: Developer Community
Previous:From: Jim C. NasbyDate: 2005-04-28 00:22:03
Subject: Re: Developer Community

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group