Hello
> If someone changes restore_command to '' then reload while crash
> recovery is running, the server stops for no valid reason.
While *crash* recovery is running? It's possible only during Point-in-Time Recovery, no?
At the beginning of validateRecoveryParameters we check ArchiveRecoveryRequested, which can be set in two cases:
* if recovery.signal found - same check on recovery start. Otherwise it is possible to early end recovery because of
emptyrestore_command. So we want to protect the user from such misconfiguration? I am fine if we decide that no
additionalhandling is needed.
* if standby.signal found - this FATAL is not reachable because StandbyModeRequested is also set.
During crash recovery validateRecoveryParameters does nothing.
> If restore_command is set to 'hoge' (literally:p, that is, anything
> unexecutable) and send SIGHUP while archive recovery is running, the
> server stops. I think we need to handle these cases more gracefully,
I think we can not perform such check reliable. As in my example earlier:
> restore_command = '. /etc/wal-g/WALG_AWS_ENV; wal-g wal-fetch "%f" "%p"'
How do we find the commands first? For any shell? And even: we learned that the binary is unexecutable. But what to do
next?
> If someone changes restore_command by mistake to something executable
> but fails to offer the specfied file even if it exists, the running
> archive recovery finishes then switches timeline unexpectedly.
Or executable file was just removed. Which is clearly a pilot error. Is this differs from changing restore_command?
>> I do not know the history of this fatal ereport. It looks like "must specify restore_command when standby mode is
notenabled" check is only intended to protect the user from misconfiguration and the rest code will treat empty
restore_commandcorrectly, just like /bin/false. Did not notice anything around StandbyMode conditions.
>
> If restore_command is not changable after server-start, it would be
> valid for startup to stop for inexecutable content for the variable
> since there's no way to proceed recovery.
Why not use local pg_wal? There may be already enough WAL.
regards, Sergei
