Re: BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write

On Thu, Jan 31, 2019 at 09:26:48PM +0900, Kyotaro HORIGUCHI wrote:
> I don't think no one expected that server follows
> recovery_target_action without setting a target, so we can change
> the behavior when any kind of target is specified. So I propose
> to follow recovery_target_action even if not rached the target
> when any recovery target isspecified.

Quoting the docs:
https://www.postgresql.org/docs/current/recovery-target-settings.html
recovery_target_action (enum)
"Specifies what action the server should take once the recovery target
is *reached*."

So what we have now is that an action would be taken iff a stop point
is defined and reached. What this patch changes is that the action
would be taken even if the stop point has *not* been reached once the
end of a WAL stream is found.

+ * to be taken regardless whether the target is reached or not .
Nit 1: Dot at the end has an extra space.

Nit 2: s/specfied/specified/

Please do not take me wrong, I can see that there could be use cases
where it is possible to take an action at the end of a WAL stream if
there is less WAL than what was planned, perhaps if the OP has set
an incorrect stop position too far in the future, still too much WAL
would have been replayed so it would make the base backup unusable for
future uses. Also, it looks incorrect to me to change an existing
behavior and to use the same semantics for triggering an action if a
stop point is defined and reached.
--
Michael