On Thu, Feb 02, 2023 at 02:01:13PM -0800, Nathan Bossart wrote:
> I've been digging into the history here. This e-mail seems to have the
> most context [0]. IIUC this was intended to prevent "fast" shutdowns from
> escalating to "immediate" shutdowns because the restore command died
> unexpectedly. This doesn't apply to archive_cleanup_command because we
> don't FATAL if it dies unexpectedly. It seems like this idea should apply
> to recovery_end_command, too, but AFAICT it doesn't use the same approach.
> My guess is that this hasn't come up because it's less likely that both 1)
> recovery_end_command is used and 2) someone initiates shutdown while it is
> running.
Actually, this still doesn't really explain why we need to exit immediately
in the SIGTERM handler for restore_command. We already have handling for
when the command indicates it exited due to SIGTERM, so it should be no
problem if the command receives it before the startup process. And
HandleStartupProcInterrupts() should exit at an appropriate time after the
startup process receives SIGTERM.
My guess was that this is meant to allow breaking out of the system() call,
but I don't understand why that's important here. Maybe we could just
remove this exit-in-SIGTERM-handler business...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com