Le mar. 29 juil. 2025 à 00:38, David G. Johnston <david.g.johns...@gmail.com> a écrit :
> On Monday, July 28, 2025, Jacob Champion <jacob.champ...@enterprisedb.com> > wrote: > >> On Mon, Jul 28, 2025 at 2:42 PM David G. Johnston >> <david.g.johns...@gmail.com> wrote: >> > I don’t understand calling out sigterm as an exception, the same >> abort-and-shutdown action happens there too. >> >> RestoreArchivedFile() has a special case for SIGTERM, though? > > > I don’t see anything calling out sigterm by name. It seems to be handled > the same as any other signal exit and, because of the “true” being passed > into wait_result_is_any_signal, identically to exit statuses 126-127 as > well. > > >> >> > And in any case signals are turned into exit status values anyway so >> naming them specifically seems redundant. > > > Ok, yeah, the C API differentiates this reality since an unhandled signal > precludes an exit status from being created. I’m fine with “…unhandled > signals causing command termination, or exit statues > 125, result in abort > and stop”. > > Thank you! Should we stick to the original wording, changing it slightly? An exception is that if the command was terminated by an unhandled signal causing command termination or an exit status above 125 (including command not found), then recovery will abort and the server will not start up. Or should we use the previous proposal (in that thread) with some adaptations? Recovery will abort and the server will not start up if any of the following events occur: the command is terminated by an unhandled signal or the command returns an exit status greater than 125 (including "command not found"). -- Jean-Christophe Arnu
