Adding another patch which is not only for recovery_target_time but also for xid, name and lsn.
> 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.
Yes, that is why I have created the patch.
>
> 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
>
If recovery pauses or a FATAL error is reported, is not important, as long as it is possible to get some more WAL and
continuerecovery. Pause has the benefit of the possibility to inspect tables in the database.
> 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.
Pausing was choosen in the patch as pause was the expected behaivior if target was reached.
And the patch does not interfere with any other functionality as far as I know.
--
Leif Gunnar Erlandsen