Horton

Re: Weird failure with latches in curculio on v15

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Fujii Masao <fujii@postgresql.org>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-02-03T07:35:29Z
Lists: pgsql-hackers 
Hi,

On 2023-02-02 14:39:19 -0800, Nathan Bossart wrote:
> 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...

I don't think you can, at least not easily. For one, we have no
guarantee that the child process got a signal at all - we don't have a
hard dependency on setsid(). And even if we have setsid(), there's no
guarantee that the executed process reacts to SIGTERM and that the child
didn't create its own process group (and thus isn't reached by the
signal to the process group, sent in signal_child()).

Greetings,

Andres Freund

Commits

  1. Avoid calling proc_exit() in processes forked by system().

  2. Move extra code out of the Pre/PostRestoreCommand() section.

  3. Revert refactoring of restore command code to shell_restore.c

  4. Refactor code in charge of running shell-based recovery commands

  5. Clean up inconsistent use of fflush().

  6. Report wait events for local shell commands like archive_command.