After studying this a bit more, I think the current behavior is totally
bogus and needs a serious rethink.
If you specify a recovery target and it is reached, recovery pauses
(depending on recovery_target_action).
If you specify a recovery target and it is not reached when the end of
the archive is reached (i.e., restore_command fails), then recovery ends
and the server is promoted, without any further information. This is
clearly wrong in multiple ways.
I think what we should do is if we specify a recovery target and we
don't reach it, we should ereport(FATAL). Somewhere around
/*
* end of main redo apply loop
*/
in StartupXLOG(), where we already check for other conditions that are
undesirable at the end of recovery. Then a user can make fixes either
by getting more WAL files to restore and adjusting the recovery target
and starting again. I don't think pausing is the right behavior, but
perhaps an argument could be made to offer it as a nondefault behavior.
There is an interesting overlap with the other thread that wants to make
"end of archive" and explicitly settable recovery target. The current
behavior, however, is more like "recovery time (say) or end of archive,
whichever happens first", which is not a behavior that is currently
selectable or intended with other methods of recovery target
specification. Also, if you want the end of the archive as your
recovery target, that currently does not respect the
recovery_target_action setting, but perhaps it should.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
