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: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, Fujii Masao <fujii@postgresql.org>, Nathan Bossart <nathandbossart@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-02-03T07:58:06Z
Lists: pgsql-hackers 
Hi,

On 2023-02-03 20:34:36 +1300, Thomas Munro wrote:
> What if we block signals, fork, then in the child, install the default
> SIGTERM handler, then unblock, and then exec the shell?

Yep.  I was momentarily wondering why we'd even need to unblock signals,
but while exec (et al) reset the signal handler, they don't reset the
mask...

We could, for good measure, do PGSharedMemoryDetach() etc. But I don't
think it's quite worth it if we're careful with signals.  However
ClosePostmasterPorts() might be a good idea? I think not doing it might
cause issues like keeping the listen sockets alive after we shut down
postmaster, preventing us from startup up again?

Looks like PR_SET_PDEATHSIG isn't reset across an execve(). But that
actually seems good?


> If SIGTERM is delivered either before or after exec (but before
> whatever is loaded installs a new handler) then the child is
> terminated, but without running the handler.  Isn't that what we want
> here?

Yep, I think so.

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.