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: | Raw Message | Whole Thread | 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
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 |
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. |