From: | "Jason L(dot) Buberel" <jason(at)buberel(dot)org> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: recovery_target_time ignored or recovery alwaysrecovers to end of WAL |
Date: | 2007-07-02 13:20:27 |
Message-ID: | 4688FB9B.3000808@buberel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Simon,
Thanks for the tip. I had assumed that so long as I set
'recovery_target_time' to a value that occurred before the 'fatal
commit' and set the 'inclusive' flag to false that I would be able to
return to just before the deletion occurred.
I'll play with it a bit more and see. I just want to know what to do in
the future should a real emergency like this occur.
Thanks,
jason
Simon Riggs wrote:
> On Sun, 2007-07-01 at 21:41 -0700, Jason L. Buberel wrote:
>
> Your example transactions are so large that going back 15 minutes is not
> enough. You'll need to go back further.
>
> recovery_target_time can only stop on a COMMIT or ABORT record. This is
> because it makes no sense to recover half a transaction, only whole
> transactions have meaning for recovery. So if the transactions are very
> large, you need to go back further.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2007-07-02 13:31:04 | Re: shmctl EIDRM preventing startup |
Previous Message | ujkavlade | 2007-07-02 13:06:11 | HAVING clause working in postgres 8.0, but not in 8.2 |