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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Juan Jose Costello Levien 2005-04-28 00:53:39 Re: Developer Community
Previous Message Jim C. Nasby 2005-04-28 00:22:03 Re: Developer Community