Re: Queries about PostgreSQL PITR

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Jayadevan M <Jayadevan(dot)Maymala(at)ibsplc(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Queries about PostgreSQL PITR
Date: 2010-07-12 06:25:08
Message-ID: AANLkTinELWs84rEou9PMt7ii6xhRRK-NUkeHXBBPle5T@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Fri, Jul 9, 2010 at 6:47 PM, Jayadevan M
<Jayadevan(dot)Maymala(at)ibsplc(dot)com> wrote:
> So recovery happened to a point after I dropped the first table and before
> I dropped
> the second table. Why ?

Because you didn't disable recovery_target_inclusive, I guess.
http://www.postgresql.org/docs/8.4/static/continuous-archiving.html#RECOVERY-TARGET-INCLUSIVE

> Is there a way in which I can now go back a bit further, and ensure I am
> back to the
> time line before I dropped either of the tables? From documentation, I
> think the answer is 'No'.
> Of course, I could try the entire recovery process once more, and provide
> a couple of minutes
> earlier time as recovery_target_time.

How about setting recovery_target_timeline to the old timeline ID (= 1)?
http://www.postgresql.org/docs/8.4/static/continuous-archiving.html#RECOVERY-TARGET-TIMELINE

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2010-07-12 07:12:41 Re: simple functions, huge overhead, no cache
Previous Message Craig Ringer 2010-07-12 06:06:43 Re: simple functions, huge overhead, no cache

Browse pgsql-performance by date

  From Date Subject
Next Message Dimitri 2010-07-12 07:17:32 Re: Slow query with planner row strange estimation
Previous Message Pierre C 2010-07-11 22:47:05 Re: Need help in performance tuning.