On Wed, Aug 17, 2016 at 12:06 AM, Stephen Frost <sfrost@snowman.net> wrote:
Greetings, * Venkata B Nagothi (nag1010@gmail.com) wrote: > 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,
PG doesn't know that there are still WALs to be replayed.
PG doesn't know that there are still WALs to be replayed. Since, i have given an particular recovery target and PG knows the current replay position,
I would say, it would be good if PG warns and pauses there by saying recovery target point is not reached.
> 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.
Agreed. Reaching end-of-WAL is not an error. It sounds more like a limitation in certain scenarios.
Reaching the end of WAL isn't an error and I don't believe it makes any sense to treat it like it is. You can specify any recovery target point you wish, including ones that don't exist, and that's not an error either.
I could see supporting an additional "pause" option that means "pause at the end of WAL if you don't reach the recovery target point". I'd also be happy with a warning being emitted in the log if the recovery target point isn't reached before reaching the end of WAL, but I don't think it makes sense to change the existing behavior.
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
