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

"Michael Paquier" <michael(at)paquier(dot)xyz> skrev 26. februar 2019 kl. 09:13:

> 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*."

I know this and recovery_target_action in my case was "pause".
Recovery target was specified with a date and time.

> 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.

Yes, and this is expected behaviour in my use case. This was a PITR scenario, to a new server, and not crash recovery.
I restored a backup and placed WAL-files in a separate directory, then I created a recovery.conf with correct recovery_target_time.
After PostgreSQL started it stopped after a short while and opened the database in read/write.
Checks showed target was not reached. Log showed that no more WAL could be found.
If PostgreSQL had followed recovery_target_action, then I could have restored the missing WAL-files and continued replay of WAL.
As this was not the case I had to restart the process from the beginning, this took many hours.
Another thing to consider is that in instances such as this one, where a lot of WAL was needed for replay, it is not always given that we have the sufficient amount of available disk space in order to store them all at the same time.

> 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.

I did not set an incorrect stop position. I see this change as something most in a similar situation would expect from their database system.

AFAIK the doc does not specify what happens if recovery_target_time is specified but not reached. But as default recovery_target_action is set to "pause" I would have assumed "pause" to be the action.

regards
Leif Gunnar Erlandsen