Re: recovery_target_time ignored or recovery always recovers to end of WAL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jason L(dot) Buberel" <jason(at)buberel(dot)org>
Cc: pgsql-general(at)postgresql(dot)org, diogob(at)gmail(dot)com
Subject: Re: recovery_target_time ignored or recovery always recovers to end of WAL
Date: 2007-07-03 15:00:45
Message-ID: 7676.1183474845@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Jason L. Buberel" <jason(at)buberel(dot)org> writes:
> Instead, in order to achieve my goal I would have to restore to that
> backup, and rely on the contents of the archive_logs to have the
> recovery process return me to the selected xid PITR.

Correct.

> So is there any way to 'trick' or force the server to forget what it
> thinks 'now' is and instead to step back to the selected xid and make
> that the new version of 'now'?

No. As an example, would you expect such a trick to reverse the effects
of a DROP TABLE? Or even just a single DELETE? That would mean we
could *never* free any storage.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Erik Jones 2007-07-03 15:05:08 Re: recovery_target_time ignored or recovery always recovers to end of WAL
Previous Message Albe Laurenz 2007-07-03 14:50:15 Re: Check whether two strs have at least one shared character.