Horton

Re: stopgap fix for signal handling during restore_command

Andres Freund <andres@anarazel.de>

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

On 2023-10-10 22:29:34 -0500, Nathan Bossart wrote:
> On Tue, Oct 10, 2023 at 09:54:18PM -0500, Nathan Bossart wrote:
> > On Tue, Oct 10, 2023 at 04:40:28PM -0700, Andres Freund wrote:
> >> I'd make these elog(PANIC), I think. The paths are not performance critical
> >> enough that a single branch hurts, so the overhead of the check is irrelevant,
> >> and the consequences of calling ProcKill() twice for the same process are very
> >> severe.
> > 
> > Right.  Should we write_stderr_signal_safe() and then abort() to keep these
> > paths async-signal-safe?
> 
> Hm.  I see that elog() is called elsewhere in proc_exit(), and it does not
> appear to be async-signal-safe.  Am I missing something?

We shouldn't call proc_exit() in a signal handler. We perhaps have a few
remaining calls left, but we should (and I think in some cases are) working on
removing those.

Greetings,

Andres Freund

Commits

  1. windows: msvc: Define STDIN/OUT/ERR_FILENO.

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

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