On 8/16/16 1:08 AM, Venkata B Nagothi wrote:
> 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. The above said parameters can be configured to pause, shutdown or prevent promotion only after reaching the recovery target point. To clarify, I am referring to a scenario where recovery target point is not reached at all ( i mean, half-complete or in-complete recovery) and there are lots of WALs still pending to be replayed - in this situation, PostgreSQL just completes the archive recovery until the end of the last available WAL (WAL file "00000001000000000000001E" in my case) and starts-up the cluster by generating an error message (saying "00000001000000000000001F" not found). Note: I am testing in PostgreSQL-9.5 LOG: restored log file "00000001000000000000001E" from archive cp: cannot stat â/data/pgrestore9531/00000001000000000000001Fâ: No such file or directory LOG: redo done at 0/1EFFDBB8 LOG: last completed transaction was at log time 2016-08-15 11:04:26.795902+10 I have used the following recovery* parameters in the recovery.conf file here and have intentionally not supplied all the WAL archives needed for the recovery process to reach the target xid. recovery_target_xid = xxxx, recovery_target_inclusive = true recovery_target_action = pause It would be nice if PostgreSQL pauses the recovery in-case its not complete (because of missing or corrupt WAL), shutdown the cluster and allows the DBA to restart the replay of the remaining WAL Archive files to continue recovery (from where it stopped previously) until the recovery target point is reached.
OK, I see what you mean. I think it would be a good idea to work through the various scenarios and define what Postgres would do in each scenario before actually creating a patch.
-- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
