Re: patch proposal
| От | Venkata B Nagothi |
|---|---|
| Тема | Re: patch proposal |
| Дата | |
| Msg-id | CAEyp7J8VSPdoOBcXf0TA4GdGfcNz3gHYZ++GV__vye0qa-iG3w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: patch proposal (Stephen Frost <sfrost@snowman.net>) |
| Ответы |
Re: patch proposal
|
| Список | pgsql-hackers |
On Wed, Aug 17, 2016 at 11:27 PM, Stephen Frost <sfrost@snowman.net> wrote:
Venkata,
* Venkata B Nagothi (nag1010@gmail.com) wrote:
> Agreed. Additional option like "pause" would. As long as there is an option
> to ensure following happens if the recovery target is not reached -
>
> a) PG pauses the recovery at the end of the WAL
> b) Generates a warning in the log file saying that recovery target point
> is not reached (there is a patch being worked upon on by Thom on this)
> c) Does not open-up the database exiting from the recovery process by
> giving room to resume the replay of WALs
One thing to consider is just how different this is from simply bringing
PG up as a warm standby instead, with the warning added to indicate if
the recovery point wasn't reached.
I am referring to a specific scenario (performing point-in time recovery) where-in a DBA attempts to bring up a standalone PG instance by restoring the backup and performing recovery to a particular recover target (XID, time or a named restore point) in the past by replaying all the available WAL archives, which is not quite possible through a warm-standby setup.
Warm standby is more of a high-availability solution and i do not think so, it addresses PITR kind of situation.
I will share more details defining PG behaviour across various recovery scenarios (as asked by David Steele) when using various recovery* parameters. Will also explain what difference the proposed patch could make.
Regards,
Venkata B N
Fujitsu Australia
В списке pgsql-hackers по дате отправления: