From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Venkata B Nagothi <nag1010(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch proposal |
Date: | 2016-08-15 16:50:53 |
Message-ID: | e0b95abd-2712-217f-e8a8-71489dec52b3@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/15/16 2:33 AM, Venkata B Nagothi wrote:
> During the recovery process, It would be nice if PostgreSQL generates an
> error by aborting the recovery process (instead of starting-up the
> cluster) if the intended recovery target point is not reached and give
> an option to DBA to resume the recovery process from where it exactly
> stopped.
Thom wrote a patch [1] recently that gives warnings in this case. You
might want to have a look at that first.
> The issue here is, if by any chance, the required WALs are not available
> or if there is any WAL missing or corrupted at the restore_command
> location, then PostgreSQL recovers until the end of the last available
> WAL and starts-up the cluster.
You can use pause_at_recovery_target/recovery_target_action (depending
on your version) to prevent promotion. That would work for your stated
scenario but not for the scenario where replay starts (or the database
reaches consistency) after the recovery target.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-08-15 17:05:01 | Re: condition variables |
Previous Message | Konstantin Knizhnik | 2016-08-15 16:32:07 | Re: WIP: Barriers |