Re: stopgap fix for signal handling during restore_command

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <fujii(at)postgresql(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: stopgap fix for signal handling during restore_command
Date: 2023-10-11 03:29:34
Message-ID: 20231011032934.GA847236@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jinser 2023-10-11 03:34:23 Re: Fix typo in psql zh_CN.po
Previous Message Noah Misch 2023-10-11 03:29:08 Re: interval_ops shall stop using btequalimage (deduplication)